Web Aplication Vulnerabilities

Web Aplication Vulnerabilities Present by: Jordan Alexander Diaz Diaz

Exploits: XSS, SQLI, Buffer Overflow These vulnerabilities continue to result in many active exploits. XSS - Cross Site Scripting, comparable to XSRF, Cross Site Request Forgery. These vulnerabilities are found in many web applications. SQLI - Structured Query Language Injection exploits weaknesses in the web application controller to data model interface. Buffer Overflows are caused by providing more data to an input variable than the amount of space allocated, overwriting memory elsewhere in the application to modify the application.

Origin and Copyright These notes are partly derived from Wikipedia entries, so as a derived work it is licenced under the GNU Free Documentation License. For further details see: http://en.wikipedia.org/wiki/Wikipedia:Copyrights http://en.wikipedia.org/wiki/Cross_site_scripting http://en.wikipedia.org/wiki/Cross_Site_Request_Forgery http://en.wikipedia.org/wiki/SQL_injection http://en.wikipedia.org/wiki/Buffer_overflow

Cross Site Scripting - XSS A Cross Site Scripting (XSS) exploit concerns the ability of a website to run scripts within the web browser, using the JavaScript language. Obviously the browser will be designed to sandbox the script, so this has restricted access to the computer running the browser. But the browser can only have low-level information to limit what the script can do, e.g. the script won't be allowed access to files on the host. So if the attack is at a higher conceptual level of abstraction - e.g. to do with what the user of the webpage thinks about the origin of the information being presented, the lower level of logic at which the browser sandboxes website scripts will not be effective.

How it was done http://www.web.onpe.gob.pe/ busquedaderesoluciones.php contained the following HTML source code which included some JavaScript. ?c_tipo=1&c_texto=<script>alert(/XSS/);</script>

How Pirate Bay boarded the MPAA <form name="form" action="http://www.mpaa.org/thank_you.asp" method="post">  <input name="txtfavoritemovie" type="hidden" size="18" maxlength="1175" value="<IMG src='http://static.thepiratebay.org/img/tpb.jpg'><BR><BR> <IFRAME width='100%' height='600px' src='http://thepiratebay.org/browse/200'>"> <input type="hidden" name="name" value="1"> <input type="submit"> </form>

Other method "<IMG src='http://static.thepiratebay.org/img/tpb.jpg‘ /> Sending the code of above or other code inside of coment of web site:

XSS - Mr Bean for Spanish President

Type 0: local or DOM-based XSS vulnerability This occurs where an attacker writes HTML including scripts into a context that the web browser treats as of local origin, allowing for unprivileged access to local objects - e.g. a file on the local system.

XSS type 0 example 1. Mallory sends a URL to Alice (via email or another mechanism) of a maliciously constructed web page. 2. Alice clicks on the link. 3. The malicious web page's JavaScript opens a vulnerable HTML page installed locally on Alice's computer. 4. The vulnerable HTML page is tricked into executing JavaScript in the computer's local zone. 5. Mallory's malicious script now may run commands with the privileges Alice holds on her own computer.

Type 1: non-persistent or reflected XSS vulnerability This arises when an attacker (Mallory) succeeds in getting a victim (Alice) to click on a supplied URL which is then submitted to another (e.g. Bob's) website. This can occur through a URL in an email to Alice sent by Mallory, to a site owned by Bob and accepting HTML input.

XSS type 1 example slide 1 1. Alice often visits a particular website, which is hosted by Bob. Bob's website allows Alice to log in with a username/password pair and store sensitive information, such as billing information. 2. Mallory observes that Bob's website contains a reflected XSS vulnerability. 3. Mallory crafts a URL to exploit the vulnerability, and sends Alice an email, making it look as if it came from Bob (ie. the email is spoofed).

XSS type 1 example slide 2 4. Alice visits the URL provided by Mallory while logged into Bob's website. 5. The malicious script embedded in the URL executes in Alice's browser, as if it came directly from Bob's server. The script steals sensitive information (authentication credentials, billing info, etc) and sends this to Mallory's web server without Alice's knowledge.

Type 2: persistent XSS vulnerability Here Mallory inserts the HTML including script directly into Bob's website, which allows users to include HTML, e.g. where social networking sites enable users to include an HTML profile. Alice, when looking at Mallory's profile or HTML message, will run the script in her web browser within the domain context of Bob, so Alice's system will treat Mallory's script as if it were from Bob.

XSS type 2 example slide 1 1. Bob hosts a web site which allows users to post messages and other content to the site for later viewing by other members. 2. Mallory notices that Bob's website is vulnerable to a type 2 XSS attack. 3. Mallory posts a message, controversial in nature, which may encourage many other users of the site to view it.

XSS type 2 example slide 2 4. Upon merely viewing the posted message, site users' session cookies or other credentials could be taken and sent to Mallory's webserver without their knowledge. 5. Later, Mallory logs in as other site users and posts messages on their behalf....

XSRF Cross Site Request Forgery Cross-site request forgery, also known as one click attack or session riding and abbreviated as CSRF or XSRF, is a kind of malicious exploit of websites. Although similar-sounding in name to cross-site scripting (XSS), it is a different and almost opposite form of attack. Whereas cross-site scripting exploits the trust a user has in a website, a cross-site request forgery exploits the trust a Web site has in a user by forging a request from a trusted user. These attacks are often less popular (so there are fewer resources available), more difficult to defend against than XSS attacks, and, therefore, more dangerous.

XSRF attack example slide 1 The attack works by including a link or script in a page that accesses a site to which the user is known to have authenticated. For example, one user, Alice, might be browsing a chat forum where another user, Mallory, has posted a message with an image that links to Alice's bank. Suppose that, as the URL for the image tag, Mallory has crafted a URL that submits a withdrawal form on Alice's bank's website. If Alice's bank keeps her authentication information in a cookie, and if the cookie hasn't expired, then Alice's browser's attempt to load the image will submit the withdrawal form with her cookie, thus authorizing a transaction without Alice's approval.

XSRF attack example slide 2 <IMG src="http://bigbank.com/transfer_money.cgi?ac=alice&pay=mallory&amount=100000" &description=completion_ac2157> Here BigBank trusts Alice's cookie becauseAlice is already logged in. It therefore assumes that the URL that comes from Alice's web browser containing Alice's cookie is authorised to transfer a large sum from Alice's to Mallory's account. Data is frequently sent from browsers to websites as part of the URL, and many websites treat the GET data entry request identically to the FORM data entry request.

XSRF Common Characteristics Involve sites that rely on a user's identity Exploit the site's trust in that identity Trick the user's browser into sending HTTP requests to a target site Involve HTTP requests that have side effects At risk are web applications that perform actions based on input from trusted and authenticated users without requiring the user to authorize the specific action. A user that is authenticated by a cookie saved in his web browser could unknowingly send an HTTP request to a site that trusts him and thereby cause an unwanted action.

SQL Injection source - http://imgs.xkcd.com/comics/exploits_of_a_mom.png Exploits of a mum

SQL Injection Attacks SQL injection is a security vulnerability that occurs in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. This is an instance of a more general class of vulnerabilities that can occur whenever one programming or scripting language is embedded inside another.

Incorrectly filtered escape characters 1 This form of SQL injection occurs when user input is not filtered for escape characters and is then passed into a SQL statement. This results in the potential manipulation of the statements performed on the database by the end user of the application. The following line of code illustrates this vulnerability: statement := "SELECT * FROM users WHERE name = '" + userName + "';" If the "userName" variable is crafted in a specific way by a malicious user, the SQL statement may do more than the code author intended.

Incorrectly filtered escape characters 2 For example, setting the "userName" variable as a' or 't'='t renders this SQL statement by the parent language: SELECT * FROM users WHERE name = 'a' or 't'='t'; If this code were to be used in an authentication procedure then this example could be used to force the selection of a valid username because the evaluation of 't'='t' is always true.

Incorrectly filtered escape characters 3 Theoretically any valid SQL command may be injected via this method, including the execution of multiple statements. The following value of "userName" in the above statement would cause the deletion of the "users" table as well as the selection of all data from the "data" table: a';DROP TABLE users; SELECT * FROM data WHERE name LIKE '% This input renders the final SQL statement as follows: SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM data WHERE name LIKE '%';

Incorrect type handling 1 This form of SQL injection occurs when a user supplied field is not strongly typed or is not checked for type constraints. This could take place when a numeric field is to be used in a SQL statement, but the programmer makes no checks to validate that the user supplied input is numeric. For example: statement := "SELECT * FROM data WHERE id = " + a_variable + ";" It is clear from this statement that the author intended a_variable to be a number correlating to the "id" field.

Incorrect type handling 2 However, if it is in fact a string then the end user may manipulate the statement as they choose, thereby bypassing the need for escape characters. For example, setting a_variable to 1;DROP TABLE users will delete the "users" table from the database as the rendered SQL would be rendered as follows: SELECT * FROM data WHERE id = 1;DROP TABLE users;

Example 02 in Sql Server http://www.web.pe/noticias/noticia.asp?id=170' update noticias set Titulo='Prueva';--

Buffer Overflow Exploits A buffer overflow occurs when more data is input into a program data storage area than the space allocated or planned for it. Everyone who has learned how to program in 'C' will have encountered buffer overflows as a common programming bug. Crackers have learned how to exploit this kind of bug in many situations where hostile data is input to an insecure program which worked correctly in test cases previously known to the developer.

Stack Buffer Overflow Exploitation 1 Programs are vulnerable to this exploit where: 1. The function return jump address on the program stack occurs in the memory segment soon after the exploitable buffer and nothing causing program failure if overwritten occurs between 2. The attacker can provide arbitrary input which overruns an exploitable buffer. 3. The attacker can calculate an alternate jump address to insert in place of the return jump address, so that the alternate jump address goes to program instructions which the attacker has inserted as part of the buffer overrun. (Use of a "landing pad" area of goto next program instructions prior to the inserted exploit code for the jump inserted by the attacker allows extra flexibility.

Stack Buffer Overflow Exploitation 2 4. The attacker can execute inserted exploit code by this means which can, with the privileges and context of the compromised program, cause actions to occur which furthers the attackers agenda, or which result in some other system security compromise. Obviously the potential system compromise will be greater when a setuid to root program, or a program running as root is exploited in this manner than if a less privileged program is exploited.

Heap Buffer Overflow Exploitation A buffer overflow occurring in the heap data area is referred to as a heap overflow and is exploitable in a different manner to that of stack-based overflows. Memory on the heap is dynamically allocated by the application at run-time and typically contains program data. Exploitation is performed by corrupting this data in specific ways to cause the application to overwrite internal structures such as linked list pointers. The canonical heap overflow technique overwrites dynamic memory allocation linkage (such as malloc meta data) and uses the resulting pointer exchange to overwrite a program function pointer.

Further Recommended Reading XSS, XSRF http://www.cert.org/advisories/CA-2000-02.html CERT® Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests http://www.cgisecurity.com/articles/xss-faq.shtml Cross Site Scripting FAQ. Good summary for non-technical users. SQL Injection http://www.unixwiz.net/techtips/sql-injection.html SQL Injection Attacks By Example Buffer Overflows http://doc.bughunter.net/buffer-overflow/smash-stack.html Smashing The Stack For Fun And Profit (Aleph One)‏

Web Aplication Vulnerabilities

More Related Content

What's hot

Viewers also liked

Similar to Web Aplication Vulnerabilities

Recently uploaded

Web Aplication Vulnerabilities