XSS Stored Attack

XSS attack is one of some web vulnerability that could very danger for web developer. If a web application support for xss attack it will be show pop up when attacker insert tag <script> on it. I show you how if a web application vulner of xss attack.

The following example is posting message web application that vulner with this attack :

If posting message success it will be save on database and it will be show when we click the title of message. When xss stored has been on web application attacker could do everything that attacker want . For example I tried insert javascript like this “<script>alert(“this vulner of XSS attack”);</script> on this web application

example :

 

when I click submit, message will be save on database and when another user read the title script will load and running :

 

there are many web application on internet could support this attack .

What Is Subnetting

Subnetting is a technique that allows network administrators to take advantage of 32 bit IP addresses that are available more efficiently. Subnetting techniques to make the network more extensive scale and not by classes dibatas IP (IP Classes) A, B, and Cto the set. With subnetting, you can create a network with hosts that are more realisticlimit as needed Subnetting provides a more flexible way to determine which parts of a32 bit IP adddress representing netword ID and which part represents the host ID.

Classes with a standard IP address, only 3 possible network IDs are available; 8 bitsfor class A, 16 bits for class B, and 24 bits for class C. Subnetting allows you to choose a random bit number (arbitrary number) to be used as a network ID.

subnets

Subnet is a network within a network of other (Class A, B, and C). Subnets are created using one or more bits in the host Class A, B, or C to widen the network ID. If thedefault network ID is 8, 16, and 24 bits, then the subnet network ID can have a lengththat is different.

How To Install WebGoat On BT5

WebGoat is a web application written in Java language with deliberate security holes for purpose of teaching security lessons using a web application. The WebGoat is maintained by OWASP (Open Web Application Security Project).

The main lessons in the WebGoat application include Cross site scripting, SQL injection, Thread safety, Hidden Form Fields, Web Services, Weak Session Cookies etc.

The WebGoat is designed to be a de-facto interactive learning environment for web application security and is being developed further to become a security benchmarking platform and a Java-based Web site Honeypot.

if you have had webgoat install file you can run it  on  your system directly.. if have not it you can  download Here

after download extract the webgoat file using command :

root@bt:~#7z x WebGoat-OWASP_Standard-5.3_RC1.7z    

then move the extract file to /pentest/web/ :

root@bt:~#mv WebGoat-5.3_RC1 /pentest/web

after moved go into the directory  /pentest/web/WebGoat-5.3_RC1

then execute command # chmod +x webgoat.sh to make webgoat to be exetcuable

root@bt:/pentest/web/WebGoat-5.3_RC1# ls -l

total 32

drwx------  6 root root 4096 2009-11-11 00:23 java

-rw-r--r--  1 root root 4675 2009-11-11 00:03 readme.txt

drwx------ 11 root root 4096 2009-11-10 14:08 tomcat

-rw-r--r--  1 root root  681 2009-11-10 22:06 webgoat_8080.bat

-rw-r--r--  1 root root  679 2009-11-10 22:05 webgoat.bat

-rw-r--r--  1 root root  951 2009-11-08 18:56 webgoat for SQL Server.bat

-rwxr-xr-x  1 root root 1708 2009-11-08 18:56 webgoat.sh

root@bt:/pentest/web/WebGoat-5.3_RC1# ls -l

total 32

drwx------  6 root root 4096 2009-11-11 00:23 java

-rw-r--r--  1 root root 4675 2009-11-11 00:03 readme.txt

drwx------ 11 root root 4096 2009-11-10 14:08 tomcat

-rw-r--r--  1 root root  681 2009-11-10 22:06 webgoat_8080.bat

-rw-r--r--  1 root root  679 2009-11-10 22:05 webgoat.bat

-rw-r--r--  1 root root  951 2009-11-08 18:56 webgoat for SQL Server.bat

-rwxr-xr-x  1 root root 1708 2009-11-08 18:56 webgoat.sh

now run webgoat using command :

root@bt:/pentest/web/WebGoat-5.3_RC1# sh webgoat.sh start80

Using CATALINA_BASE:   ./tomcat

Using CATALINA_HOME:   ./tomcat

Using CATALINA_TMPDIR: ./tomcat/temp

Using JRE_HOME:        /usr/lib/jvm/java-6-openjdk/bin/../

Using CLASSPATH:       ./tomcat/bin/bootstrap.jar

  Open http://127.0.0.1/WebGoat/attack

  Username: guest

  Password: guest

  Or try http://guest:guest@127.0.0.1/WebGoat/attack 

if webgoat have running, open your web browser :

than write url http://127.0.0.1/WebGoat/attack

you will met username and password enter...

enter username : guest

password :guest 

try until you can ..!!!

  

DVWA Upload with low,medium and high leveling

• low level

for the first I want to try  how to hack upload feature with DVWA (Damn Vulnerabl Web App) and now let see the image in below that is an interface of upload web application

on above use the low leveling testing its very easy to upload a php on it, I only choose a file and then click  upload, it will be successfully uploaded. the image like below.

after successfully you can access the directory where you were uploaded that file http://172.17.51.105/akatsuki/vulnerabilities/upload/../../hackable/uploads/shell.php

•  medium level

At this opportunity I will going to try upload file php same with low level, like on above but it cant be successfully because the web application only for image/jpg file upload. don't worry!! we can intercept the POST data using burpsuit tools..you can get more helps about tools with "burpsuit help" setting Proxy at your web browser using default setting on port 8080.
before upload,  you should view the source code of upload

let see this source if (($uploaded_type == "image/jpeg") && ($uploaded_size < 100000)){ 
the application just allow image or jpg  and size of file to upload. if like this rename your file name like this "shell.php.jpg" when you click upload it will not send to server directly but all of it will intercept on burpsuit if you are direct intercept it ..file will be successfully uploaded but file just image extension not php . let see the image below

      
before you are intercept, erase extension *.jpg on filename like this before="shell.php.jpg" after="shell.jpg" then click intercept.. and then file will successfully uploaded. its easy job!!!...heheh

• high level      

and when i try looking for the vulnerable i found any trouble during testing, cause according to me this web app has a high security.

I tried to upload a php file and I used local proxi to intercept the Post data form the web with burpsuit application for more information about burpsuit visit ( burpsuit help)  than I tried to edit some of which are on it but still the file can not be upload. and than i tried to upload double extension file like this upload.php.jpg but still same with testing above  

let see the form source html for upload file

       

Blind SQL Injection

When an attacker executes SQL Injection attacks, sometimes the server responds with error messages from the database server complaining that the SQL Query's syntax is incorrect. Blind SQL injection is identical to normal SQL Injection except that when an attacker attempts to exploit an application, rather then getting a useful error message, they get a generic page specified by the developer instead. This makes exploiting a potential SQL Injection attack more difficult but not impossible. An attacker can still steal data by asking a series of True and False questions through SQL statements.

An attacker may verify whether a sent request returned True or False in a few ways:

Having a simple page, which displays article with given ID as the parameter, the attacker may perform a couple of simple tests if a page is vulnerable to SQL Injection attack.

Example URL:

http://newspaper.com/items.php?id=2

sends the following query to the database:

SELECT title, description, body FROM items WHERE ID = 2

The attacker may try to inject any (even invalid) query, what should cause the query to return no results:

http://newspaper.com/items.php?id=2 and 1=2

Now the SQL query should looks like this:

SELECT title, description, body FROM items WHERE ID = 2 and 1=2

Which means that the query is not going to return anything.

If the web application is vulnerable to SQL Injection, then it probably will not return anything. To make sure, the attacker will certainly inject a valid query:

http://newspaper.com/items.php?id=2 and 1=1

If the content of the page is the same, then the attacker is able to distinguish when the query is True or False.

What next? The only limitations are privileges set up by the database administrator, different SQL dialects and finally the attacker's imagination.

RDBMS fingerprinting

If the attacker is able to determine when his query returns True or False, then he may fingerprint the RDBMS. This will make the whole attack much easier to him. One of the most popular methods to do this is to call functions which will return the current date. MySQL, MS SQL or Oracle have different functions for that, respectively now(), getdate(), and sysdate().

Timing Attack

A Timing Attack depends upon injecting the following MySQL query:

SELECT IF(expression, true, false)

Using some time-taking operation e.g. BENCHMARK(), will delay server responses if the expression is True.

BENCHMARK(5000000,ENCODE('MSG','by 5 seconds'))

- will execute 5000000 times the ENCODE function.

Depending on the database server performence and its load, it should take just a moment to finish this operation. The important thing is, from the attacker's point of view, to specify high number of BENCHMARK() function repetitons, which should affect the server response time in a noticeable way.

Example combination of both queries:

1 UNION SELECT IF(SUBSTRING(user_password,1,1) = CHAR(50),BENCHMARK(5000000,ENCODE('MSG','by 5 seconds')),null) FROM users WHERE user_id = 1;

If the server response was quite long we may expect that the first user password character with user_id = 1 is character '2'.

(CHAR(50) == '2')

Using this method for the rest of characters, it's possible to get to know entire password stored in the database. This method works even when the attacker injects the SQL queries and the content of the vulnerable page doesn't change.

Obviously, in this example the names of the tables and the number of columns was specified. However, it's possible to guess them or check with a trial and error method.

Other databases than MySQL also have implemented functions which allow them to use timing attacks:

• MS SQL 'WAIT FOR DELAY '0:0:10
• PostgreSQL - pg_sleep()

Conducting Blind_SQL_Injection attacks manually is very time consuming, but there are a lot of tools which automate this process. One of them is SQLMap (http://sqlmap.sourceforge.net/) partly developed within OWASP grant program. On the other hand, tools of this kind are very sensitive to even small deviations from the rule. This includes:

• scanning othe WWW cluster, where clocks are not ideally synchronized,
• WWW services where argument acquiring method was changed, e.g. from /index.php?ID=10 to /ID,10

source https://www.owasp.org/index.php/Blind_SQL_Injection

Data Validation Testing

LDAP INJECTION (OWASP-DV-006)

LDAP is an acronym for Lightweight Directory Access Protocol. It is a paradigm to store information about users, hosts and
many other objects. LDAP Injection is a server side attack, which could allow sensitive information about users and hosts
represented in an LDAP structure to be disclosed, modified or inserted.
This is done by manipulating input parameters afterwards passed to internal search, add, and modify functions.
http://www.akakom.ac.id/ldapsearch?login=iang
this was found page like bellow

ORM INJECTION (OWASP-DV-007)

Data Validation Testing

ORACLE TESTING

Web based PL/SQL applications are enabled by the PL/SQL Gateway - it is the component that translates web requests into
database queries. Oracle has developed a number of software implementations ranging from the early web listener product
to the Apache mod_plsql module to the XML Database (XDB) web server. All have their own quirks and issues, each of
which will be thoroughly investigated in this paper. Products that use the PL/SQL Gateway include, but are not limited to,
the Oracle HTTP Server, eBusiness Suite, Portal, HTMLDB, WebDB and Oracle Application Server.

Data Validation Testing

SQL INJECTION (OWASP-DV-005)


A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application.
A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete),
execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file
existing on the DBMS file system and, in some cases, issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to affect the execution of
predefined SQL commands.

when i tried to access for phpmyadmin page and i insert for username : 1 ' or '1' = '1 and password : 1 ' or '1' = '1 it is able go to into admin page. like this

i tried to insert url like this http://www.akakom.ac.id/index.php?username=1'%20or%20%20'1'%20='1&password=1'%20or%20'1'='1 but nothing were happen

Blind SQL Injection Testing

We have pointed out that there is another category of SQL injection, called Blind SQL Injection, in which nothing is known
on the outcome of an operation. For example, this behavior happens in cases where the programmer has created a custom
error page that does not reveal anything on the structure of the query or on the database. (The page does not return a SQL
error, it may just return a HTTP 500).
By using the inference methods, it is possible to avoid this obstacle and thus to succeed to recover the values of some
desired fields. This method consists of carrying out a series of boolean queries to the server, observing the answers and
finally deducing the meaning of such answers. We consider, as always, the www.example.com domain and we suppose that
it contains a parameter named id vulnerable to SQL injection. This means that carrying out the following request:



when i try url : htt://www.akakom.ac.id/index.php?id=1' i was found a page like this

but if I change id=5 or 6 it bring me to the akakom.ac.id home page..???? what happen
http://www.akakom.ac.id/index.php?id=-6+UNION+SELECT+1,2,3,4,5,6,7-- not found anything

Data Validation Testing

Testing for Reflected Cross Site Scripting (OWASP-DV-001)

In Cross Site Scripting (XSS) testing, we test if it is possible to manipulate the input parameters of the application so that it

generates malicious output. We find an XSS vulnerability when the application does not validate our input and creates an

output that is under our control. This vulnerability leads to various attacks, for example, stealing confidential information

(such as session cookies) or taking control of the victim's browser. An XSS attack breaks the following pattern: Input ->

Output == cross-site scripting

when i tried for testing XXS vulnerability for url akakom .ac.id/index.php?login=<script>alert(coba</script> i was found an attempt  like below :

this attempt not allow for input script tag.

TESTING FOR STORED CROSS SITE SCRIPTING (OWASP-DV-002)

Stored Cross Site Scripting (XSS) is the most dangerous type of Cross Site Scripting. Web applications that allow users to

store data are potentially exposed to this type of attack. This chapter illustrates examples of stored cross site scripting

injection and related exploitation scenarios.

I try for use BeEF

when i click apply config i was on the akakom.ac.id page.

TESTING FOR DOM BASED CROSS SITE SCRIPTING (OWASP-DV-003)

DOM-based Cross-Site Scripting is the de-facto name for XSS bugs which are the result of active content on a page, typically

JavaScript, obtaining user input and then doing something unsafe with it to lead to an XSS bug. This document will only

discuss JavaScript bugs which lead to XSS.

The DOM, or Document Object Model is the structural format that may be used to represent documents in the browser.

The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a

session cookie. The DOM is also used by the browser for security - for example to limit scripts on different domains

obtaining session cookies for other domains. A DOM-based cross site scripting vulnerability may occur when active content,

such as a JavaScript function, is modified by a specially crafted request such that a DOM element that can be controlled by

an attacker.

There have been very few papers published on this topic and, as such, very little standardization of its meaning and

formalized testing exists.

i cant do this phase because this web application not allow for input script in url.

TESTING FOR CROSS SITE FLASHING (OWASP-DV-004)

ActionScript is the language, based on ECMAScript, used by Flash applications when dealing with interactive needs.

ActionScript, like every other language, has some implementation patterns which could lead to security issues.

In particular, since Flash applications are often embedded in browsers, vulnerabilities like DOM based Cross Site Scripting

could be present in flawed Flash applications.

Sorry I can do this phase and i just read for

Understanding Flash Player 9 April 2008 Security Update compatibility

obe released a security update for Flash Player 9 (Flash Player 9,0,124,0) on April 8, 2008, to strengthen the security of Adobe Flash Player for our customers and end users, and to provide further mitigations for previously disclosed vulnerabilities. The Flash Player security update provides further mitigations for issues listed in the December 2007 Security Bulletin APSB07-20 for DNS rebinding and cross-domain policy file vulnerabilities, andSecurity Advisory APSA07-06 for cross-site scripting vulnerabilities in SWFs.

Customers are advised to review the following Flash Player updates to determine if their content will be impacted, and to begin implementing necessary changes immediately to help ensure a seamless transition. This document provides an overview of the upcoming Flash Player changes, links to TechNotes, and relevant documentation to help you better prepare.

If any of the following situations apply, you should read this article in detail:

• You use sockets or XMLSockets, regardless of the domain to which you are connecting
• You use addRequestHeader or URLRequest.requestHeaders in any network API call when sending or loading data cross-domain
  or
  You provide access to content on remote domains as a web service provider
• You have SWFs that are exported for Flash Player 7 (SWF7) or earlier that communicate with the hosting HTML by any means
• You use "javascript:" through network APIs to communicate outside a SWF

Adobe also recommends that customers subscribe to the Security Notification Service to receive e-mail notification for the final security bulletin and advisory releases.

A socket policy file will always be required for all socket connections

This security update will make the optional socket policy file changes introduced in Flash Player 9,0,115,0 mandatory. A socket policy file is a policy file deployed by a socket. The default socket meta-policy is "all", so socket policy files can be loaded from the socket master policy port (843) or from a custom port.

Note that with this change in Flash Player, HTTP policy files will no longer permit socket access. Flash Player has two types of policy files: HTTP policy files that are crossdomain.xml files on a server and define whether SWFs from other domains can load that server's content; and socket policy files, which define what ports Flash Player can connect to via socket or XMLSocket connections. In the latest Flash Player, the rules regarding socket policy files have changed.

These changes support the goal of DNS hardening, which helps to ensure that ActionScript cannot be used as a means for a DNS rebinding attack (as referenced in Security Bulletin APSB07-20) that could result in an unauthorized socket connection. In the previous update (Flash Player 9,0,115,0), implementing socket policy files was optional; violations of the strict policy file rules result only in warnings in Debug versions of Flash Player. In this update of Flash Player, these warnings are now errors and SWF files that depend on the older socket policy rules may stop functioning as intended.

Flash Player 9,0,115,0 introduced the following concepts:

• Socket master policy files, which are served from the fixed TCP port number 843 (this provides a standard port to serve a socket policy file from a host)
• Socket meta-policies, a "policy on policies" that allows a server administrator to designate what socket policy files are permitted to exist on a server
• Strict socket rules, which require a socket policy file for socket connections

What is impacted?

Any content using sockets or XMLSockets, including configurations in which the following is true:

• A SWF is currently relying on a crossdomain.xml file in the root directory of a web server to authorize socket connections back to the same host on ports greater than 1024
• A SWF attempts a socket or XMLSocket connection back to its own host without performing aloadPolicyFile call to retrieve a socket policy file
• A SWF attempts a socket or XMLSocket connection back to its own host and loads a policy file that does not list its own domain within the allowed domains

What do I need to do?

Impacted customers should first review the socket policy files section of the Flash Player Developer Center article,Policy file changes in Flash Player 9, in order to learn the new rules and changes. For details on how to determine if your site is affected by this change, see the following TechNote (kb403364): Sockets no longer functional in Flash Player versions greater than 9,0,115,0.

To update your content, you need to create a socket policy file to permit connections to the host socket. The policy file can be served from either the socket master policy port 843 or from the destination port of the socket connection. The socket policy file will need to include all domains that are allowed to connect to the socket, including itself. If the socket policy file is hosted from the master policy file location, be sure to include meta-policies where socket policy files are allowed to be located. You may need to check that your content performs aloadPolicyFile call to ensure that Flash Player is aware of where to load the policy file from. Use the instructions for configuring policy file logging in Tech Note kb403364 to verify your changes.

A policy file will be required to send headers across domains

At this time, Flash Player allows SWFs to set arbitrary HTTP request headers on GET and POST requests, with the exception of the blacklist of prohibited headers. The April 2008 Flash Player update adds a new security feature to perform a cross-domain policy file check before allowing SWFs to send headers to another domain. This change helps improve web site security by helping to defend against malicious HTTP headers sent by content from other domains. The feature will also help to mitigate a potential UPnP issue (VU#347812) in which routers fail to correctly handle unexpected header values.

In order for a SWF to send a header anywhere other than its own host, the origin domain of the SWF must have explicit permission from the host to which the header is being sent, in the form of a policy file. The existing policy file model will apply, with the same file locations and ActionScript APIs, but a new syntax will be required. To specify header-sending rights, use this new tag: <allow-http-request-headers-from>.

Flash Player will continue to allow any header not on the blacklist to be sent to the host of the SWF, and additional headers will be added to the blacklist as needed. As a result of this new security feature, the HTTP Authorization header, which was added to the blacklist in Flash Player 9,0,115,0, will be removed from the blacklist but will follow the new cross-domain policy file rules.

What and who is impacted?

The following are impacted:

• Any application that is sending custom HTTP headers to a different domain or host than the sending SWF's origin, using the ActionScript 2.0 XML.addRequestHeader or LoadVars.addRequestHeader methods, or the ActionScript 3.0 URLRequest.requestHeaders property
• Web service providers that wish to make their services available to Flash based applications hosted on another domain
• Applications that were impacted by the restriction on HTTP Authorization headers in Flash Player 9,0,115,0

What do I need to do?

Impacted customers should arrange for a policy file to be added or updated to include the new header policy tags on the site to which the headers are being sent. Additionally, if the crossdomain.xml policy file is in a non-default location—a directory other than the server's document root—customers may need to add an ActionScript call toloadPolicyFile and republish the affected SWFs.

As a reminder, Adobe strongly encourages customers to implement meta-policy tags within crossdomain.xml in preparation for future changes to cross-domain policy file behavior. The meta-policy file is optional in Flash Player 9,0,115,0 and will throw a security warning but is expected to become mandatory and throw a security error in a future release.

For more details on the new cross-domain policy file tag and syntax, and affected APIs, see the following TechNote (kb403185): Arbitrary headers fail to be sent from the Flash Player to a remote domain.

The allowScriptAccess default will always be "sameDomain"

The allowScriptAccess default, which is used when the parameter is not specified, will be updated from "always" to "sameDomain" for all SWFs version 7 and earlier. This changes the behavior of older SWFs to match the current security model and provide greater security by default. The allowScriptAccess permission mechanism is an HTML property of the <object> and <embed> tags that controls the ability of a SWF to call JavaScript code in the surrounding HTML file. The "always" default setting for older SWFs may expose sites to potential cross-site scripting attacks, such as the ones described in Adobe Security Advisory APSA07-06.

What may be impacted?

The change in default behavior may impact content that uses fscommand() and/orgetURL("javascript:...") if all of the following are true:

• The SWF file was published for SWF version 7 or earlier.
• The HTML that sources the SWF file does not specify a value for the allowScriptAccess parameter in the<object>/<embed> tags.
• The HTML and SWF files are served from different domains, or from different hostnames within the same domain. For example, an HTML page on www.mysite.com sources a SWF file from www.anothersite.com or fromcontent.mysite.com.
• The ActionScript code in the SWF file calls JavaScript code in the HTML file, using either fscommand() orgetURL("javascript:...").

Other cases that may be impacted include:

• SWF version 8 (or later) parent SWF loading a remote SWF version 7 and earlier child
• Hosting a SWF without surrounding HTML

What do I need to do?

If this change impacts your content, you can explicitly specify allowScriptAccess="always" in the HTML page where the problem occurs. For websites that host a SWF without surrounding HTML, you will need to add the appropriate surrounding HTML to set Flash Player to run in a less privileged mode.

Be aware that doing this grants permission for the sourced SWF file, and any SWF file that it loads, to execute JavaScript code in the context of your HTML file. If you control the SWF that is sourced, it is appropriate to grant this permission, but if you do not control that SWF, or any SWF that it may load, then you may want to consider carefully whether allowScriptAccess="always" exposes your HTML page to abuse.

"javascript:" URLs will be prohibited in networking APIs, except getURL(), navigateToURL(), and HTML-enabled text fields

To help prevent script execution actions in SWFs that were not intended by the content author, APIs that are not specifically designed for browser interaction will no longer allow "javascript:" URLs. However, getURL() andnavigateToURL() will continue to accept them.

These "javascript:" URLs were not intended to be permitted within all networking APIs, and this new behavior helps provide greater security for customers and end users. As an example of a potential vulnerability of this type, consider a SWF that is designed to call Loader.load(), which can be passed a URL supplied in a query string parameter. The developer may expect only "http:" calls but may be passed "javascript:" from an attacker. Validating input is a best practice for helping to protect your site from a potential attack; however, it is a step that many developers fail to take.

This change to the networking APIs further helps mitigate cross-site scripting injections that may result from improper input validation, such as the ones described in Adobe Security Advisory APSA07-06.

What may be impacted?

Content that uses "javascript:" URLs within networking APIs. Note that "vbscript:" is treated the same as "javascript:" in this context.

What should I do?

If your content is using "javascript:" within the prohibited networking APIs, you will need to rewrite your content. Developers are encouraged to use the ExternalInterface class for JavaScript-to-ActionScript communication.

Where to go from here

Review Creating more secure SWF web applications in the Flash Player Developer Center for more tips on how to develop more secure code. Also, learn how the Flash Player 9 security architecture and new APIs help you deliver trusted content to your users in the Flash Player 9 security white paper.