On this site (archived snapshot) under “The Theory of XSS’, it says:
the hacker infects a legitimate web page with his malicious client-side script
My first question on reading this is: if the application is deployed on a server that is secure (as is the case with a bank for example), how can the hacker ever get access to the source code of the web page? Or can he/she inject the malicious script without accessing the source code?
With cross-site scripting, it's possible to infect the HTML document produced without causing the web server itself to be infected. An XSS attack uses the server as a vector to present malicious content back to a client, either instantly from the request (a reflected attack), or delayed though storage and retrieval (a stored attack).
An XSS attack exploits a weakness in the server's production of a page that allows request data to show up in raw form in the response. The page is only reflecting back what was submitted in a request... but the content of that request might hold characters that break out of ordinary text content and introduce HTML or JavaScript content that the developer did not intend.
Here's a quick example. Let's say you have some sort of templating language made to produce an HTML page (like PHP, ASP, CGI, or a Velocity or Freemarker script). It takes the following page and substitutes "<?=$name?>" with the unescaped value of the "name" query parameter.
<html>
<head><title>Example</title></head>
<body>Hi, <?=$name?></body>
</html>
Someone calling that page with the following URL:
http://example.com/unsafepage?name=Rumplestiltskin
Should expect to see this message:
Hi, Rumplestiltskin
Calling the same page with something more malicious can be used to alter the page or user experience substantially.
http://example.com/unsafepage?name=Rumplestiltskin<script>alert('Boo!')</script>
Instead of just saying, "Hi, Rumplestiltskin", this URL would also cause the page to pop up an alert message that says, "Boo!". That is, of course, a simplistic example. One could provide a sophisticated script that captures keystrokes or asks for a name and password to be verified, or clears the screen and entirely rewrites the page with shock content. It would still look like it came from example.com, because the page itself did, but the content is being provided somewhere in the request and just reflected back as part of the page.
So, if the page is just spitting back content provided by the person requesting it, and you're requesting that page, then how does a hacker infect your request? Usually, this is accomplished by providing a link, either on a web page or sent to you by e-mail, or in a URL-shortened request, so it's difficult to see the mess in the URL.
<a href="http://example.com?name=<script>alert('Malicious content')</script>">
Click Me!
</a>
A server with an exploitable XSS vulnerability does not run any malicious code itself-- its programming remains unaltered-- but it can be made to serve malicious content to clients.
That attacker doesn't need access to the source code.
A simple example would be a URL parameter that is written to the page. You could change the URL parameter to contain script tags.
Another example is a comment system. If the website doesn't properly sanitize the input/output, an attacker could add script to a comment, which would then be displayed and executed on the computers of anyone who viewed the comment.
These are simple examples. There's a lot more to it and a lot of different types of XSS attacks.
It's better to think of the script as being injected into the middle of the conversation between the badly coded web page and the client's web browser. It's not actually injected into the web page's code; but rather into the stream of data going to the client's web browser.
There are two types of XSS attacks:
Non-persistent: This would be a specially crafted URL that embeds a script as one of the parameters to the target page. The nasty URL can be sent out in an email with the intent of tricking the recipient into clicking it. The target page mishandles the parameter and unintentionally sends code to the client's machine that was passed in originally through the URL string.
Persistent: This attack uses a page on a site that saves form data to the database without handling the input data properly. A malicious user can embed a nasty script as part of a typical data field (like Last Name) that is run on the client's web browser unknowingly. Normally the nasty script would be stored to the database and re-run on every client's visit to the infected page.
See the following for a trivial example: What Is Cross-Site Scripting (XSS)?
Related
I have watched lots of articles about XSS attack,
but one thing that make me confused is that, how the script injection works actually?
For example, if attackers enter something like <script>alert('Attack!')</script>as the input, why it can stay in the browser permanantly and every user visiting the website can see the alert.
From my understanding, after attackers's input, a POST request will be sent with payload <script>alert('Attack!')</script>. Meanwhile the <header> tag or <script> should only be manipulated on Client Side Source Code/Web Server.
How can it work?
The easiest way to understand the classic XSS mechanism:
If there are no security mesurements, an Attacker inputs the script into a comment section's textbox under an article and then sends it in. This way the script gets stored in the server's database. Every time someone visits that page with the comment section the script will be loaded on the visitor's client side.
To remediate that sanitize input, escape output and use Content-Security-Policy.
There are several types of XSS vulnerabilities.
I'll assume you are talking about a persistent-XSS since that's one type related to your question.
In a persistent-XSS vulnerability, you can POST a request which is then stored in the server-side backend of the application (i.e. a database).
For example, a table in a database storing the comments sections of an article.
When other clients of the application then request that page, the server responds with the related article HTML page including the comments section, where the attacker's payload exists. Then, each client receiving that HTML page, will also receive a comment with a malicious <script>payload</script> script.
From here, the client's browser automatically renders the HTML and executes <script> tags as legitimate JS code received from the server.
Since this code was injected by an attacker, and runs in the clients' browsers, it can be harmful - stealing the client's cookies, session keys, etc. and sending them to a remote server.
I cannot understand what damage does an XSS attack do. When I add to input, e.g onmouse() function and it display an image, this image will not appear for another user, but for me and will disappear after refreshing. how can we save it on the server via html?
XSS attacks work by exploiting vulnerabilities in a website code.
To take a trivial example:
Given an input which prompts the user to enter their name and then responds with "Hello, YOUR NAME". If the site just echos back what was input unchanged (i.e. without XSS protection) then someone could type <script> ... </script> and run some JavaScript on the site.
If that's the case then an attacker could write a form on their site but set the action to that page. They could then have a hidden input containing some JavaScript. Then they could submit the form with JS.
Now, if the attacker tricked the victim into visiting the attacker's site, the form would be submitted to the original site by the victim's browser and the JS would run in their browser.
The JS could then do something bad such as copying data out of their cookies and sending it to the attacker. The attacker could then inject that cookie into their browser and use the original site while logged in as the victim.
Now imagine if the original site was your online banking or webmail. All your personal data would be available to the attacker.
That example is of a reflected XSS attack.
The other kind of attack is a stored XSS attack.
Take, for example, a forum. It allows you to post messages. These are saved to a database and displayed to all the visitors.
Now if the data stored in the database was echoed back without XSS protection then the JS would run for everyone visiting the site.
So in short:
how can we save it on the server via html?
You can't use HTML to do this.
You need to send an HTTP request (stored) or cause the victim to do so (stored or reflected) which exploits a flaw in the site's code.
I understand the scenario of stealing information with XSS on a GET post as below workflow:
Hacker identifies a page from a web application with vulnerability of being XSS injected through query string parameters.
Hacker composes a url with XSS injected query string appended.
Hacker sends the url to a victim, for example, by email.
Victim receives the mail and clicks on the url (suppose the victim has less knowledge of security).
The opened web page has XSS injected, any further action on the page could result in a security issue.
This is possible because clicking on the url link will open the web page in GET mode. So, I am wondering if the page is XSS vulnerable for POST request, will it be a security issue? I could not figure out a "reasonable" attack workflow.
So, I am wondering if the page is XSS vulnerable for POST request, will it be a security issue?
Of course it would be. Why should the method via which external code is embedded matter at all? That it does happen is the problem, not how.
I could not figure out a "reasonable" attack workflow.
Consider a simple HTML form, that gets pre-populated with the previous user input after a failed server-side validation.
If this pre-popuplating allows XSS (basically meaning, escaping all data before outputting it in an HTML context was neglected) – then I could easily set up a form in my own page, have its action attribute point to your form handling address, and pass any data I like via hidden fields – and have to user send that data to your server via a simple submit button, that is maybe formated to look just like a normal link, and only saying “click here to go to example.com”. The user expects that to just ”normally” open a page like any other link – but in reality it send values that triggers displaying the form with pre-populated fields again.
Et voilà, XSS attack successfully performed.
(All that under the premise that the target site does not have additional security against “foreign” form data in place.)
The attacker could also build a 'data:' URL containing an auto-submitting form:
data:text/html;base64,PGh0bWw+CiAgPGJvZHkgb25sb2FkPSJkb2N1bWVudC5mb3Jtc1swXS5zdWJtaXQoKSI+CiAgICA8Zm9ybSBtZXRob2Q9InBvc3QiIGFjdGlvbj0iaHR0cDovL2xvY2FsaG9zdCI+CiAgICAgIDxpbnB1dCB0eXBlPSJoaWRkZW4iIG5hbWU9ImVybnN0IiB2YWx1ZT0iPHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4iPgogICAgPC9mb3JtPgo8L2h0bWw+
which is equivalent to navigating to a page containing this markup:
<html>
<body onload="document.forms[0].submit()">
<form method="post" action="...">
<input type="hidden" name="ernst" value="<script>alert('XSS')</script>">
</form>
</html>
Just went through this exact issue while performing a penetration test for a client. When reporting, we usually try to show a proof of concept exploit using a GET request as this is much easier. Remember too that some servers may allow you to change a POST to a GET request. Some servers will also accept POST parameter values in a URL. In my most recent experience, the server would only accept a request as a POST with the input entered into the form fields. The only thing that stopped an XSS attack was the fact that they had Cross Site Request Forgery prevention in place (via ViewState). So, in this case, it is simply a reflection fault. Still not good, but not as bad. You should ALWAYS use both ingress and egress filtering and NEVER trust user-controllable data.
My web application displays some sensitive information to a logged in user. The user visits another site without explicitly logging out of my site first. How do I ensure that the other site can not access the sensitive information without accept from me or the user?
If for example my sensitive data is in JavaScript format, the other site can include it in a script tag and read the side effects. I could continue on building a blacklist, but I do not want to enumerate what is unsafe. I want to know what is safe, but I can not find any documentation of this.
UPDATE: In my example JavaScript from the victim site was executed on the attacker's site, not the other way around, which would have been Cross Site Scripting.
Another example is images, where any other site can read the width and height, but I don't think they can read the content, but they can display it.
A third example is that everything without an X-Frame-Options header can be loaded into an iframe, and from there it is possible to steal the data by tricking the user into doing drag-and-drop or copy-and-paste.
The key point of Cross Site Attack is to ensure that your input from user which is going to be displayed, is legal, not containing some scripts. You may stop it at the beginning.
If for example my sensitive data is in JavaScript format, the other site can include it in a script tag
Yep! So don't put it in JavaScript/JSONP format.
The usual fix for passing back JSON or JS code is to put something unexecutable at the front to cause a syntax error or a hang (for(;;); is popular). So including the resource as a <script> doesn't get the attacker anywhere. When you access it from your own site you can fetch it with an XMLHttpRequest and chop off the prefix before evaluating it.
(A workaround that doesn't work is checking window.location in the returned script: when you're being included in an attacker's page they have control of the JavaScript environment and could sabotage the built-in objects to do unexpected things.)
Since I did not get the answer I was looking for here, I asked in another forum an got the answer. It is here:
https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.security/9U6HTOh-p4g
I also found this page which answers my question:
http://code.google.com/p/browsersec/wiki/Part2#Life_outside_same-origin_rules
First of all like superpdm states, design your app from the ground up to ensure that either the sensitive information is not stored on the client side in the first place or that it is unintelligible to a malicious users.
Additionally, for items of data you don't have much control over, you can take advantage of inbuilt HTTP controls like HttpOnly that tries to ensure that client-side scripts will not have access to cookies like your session token and so forth. Setting httpOnly on your cookies will go a long way to ensure malicious vbscripts, javascripts etc will not read or modify your client-side tokens.
I think some confusion is still in our web-security knowledge world. You are afraid of Cross Site Request Forgery, and yet describing and looking for solution to Cross Site Scripting.
Cross Site Scripting is a vulnerability that allows malicious person to inject some unwanted content into your site. It may be some text, but it also may be some JS code or VB or Java Applet (I mentioned applets because they can be used to circumvent protection provided by the httpOnly flag). And thus if your aware user clicks on the malicious link he may get his data stolen. It depends on amount of sensitive data presented to the user. Clicking on a link is not only attack vector for XSS attack, If you present to users unfiltered contents provided by other users, someone may also inject some evil code and do some damage. He does not need to steal someone's cookie to get what he wants. And it has notnig to do with visiting other site while still being logged to your app. I recommend:XSS
Cross Site Request Forgery is a vulnerability that allows someone to construct specially crafted form and present it to Logged in user, user after submitting this form may execute operation in your app that he didin't intended. Operation may be transfer, password change, or user add. And this is the threat you are worried about, if user holds session with your app and visits site with such form which gets auto-submited with JS such request gets authenticated, and operation executed. And httpOnly will not protect from it because attacker does not need to access sessionId stored in cookies. I recommend: CSRF
Same Origin Policy(SOP) is often mentioned together with Cross Site Scripting(XSS). But it seems that in the world with SOP, XSS still happens from time to time.
So I am never clear about what exactly kind of attacks do Same Origin Policy prevent?
In other words, imagine a world without SOP, what other power a malicious attacker could gain compared to the real world with SOP?
I read on this website(http://security.stackexchange.com/questions/8264/why-is-the-same-origin-policy-so-important) that "Assume you are logged into Facebook and visit a malicious website in another browser tab. Without the same origin policy JavaScript on that website could do anything to your Facebook account that you are allowed to do.". This actually makes me even more confused because I have never heard of any mechanism for webpage in one tab manipulating other tabs even from the same domain.
It is also mentioned (more explicitly) here (http://javascript.info/tutorial/same-origin-security-policy) that SOP prevents script in one window to manipulate DOM elements in another window. But I really cannot relate the example to what is explained (what does window mean here? it seems that the example is talking about iframe).
To sum up, can anyone give some concrete examples of what can happen if there were no SOP?
Also, I am curious about how script in one window can manipulate DOM elements in another window assuming the two window are from the same domain. But this is not the main course of this question
Thank you!
I have never heard of any mechanism for webpage in one tab manipulating other tabs [...] it seems that the example is talking about iframe
iframe is the easiest but not the only way of getting cross-window scripting. Another way to do it would be for the attacker page to window.open a document from facebook.com into a new tab. Because open returns a handle to the tab's window object, it is possible for script in one tab to interact with content in another tab.
Without the SOP, that script could fill in and submit forms in that tab on your behalf.
XSS still happens from time to time. So I am never clear about what exactly kind of attacks do Same Origin Policy prevent?
Without SOP, every web page is vulnerable to XSS and no-one can ever be secure.
With SOP, web pages are secure against XSS unless their authors make a mistake. XSS still happens from time to time because site authors do, unfortunately, make mistakes.
One example: for malicious web page it would be possible to make some javascript ajax requests to other web page where the user is already logged in the user's context. This other page would assume that the request comes from authorized user.
For example malicius script could make some ajax calls to Facebook and post new status or to bank transaction service and make a transfer if only the user is logged in to Facebook or his bank. People usually open many pages in browser tabs at the same time, so it would be very probable that someone browsing the malicious web page is at the same time logged to some sensitive service that could be hacked that way.