XSS practical example?

I understand quite well how XSS works in theory, however I lack the knowledge and imagination to see how an attacker would actually make use of a stolen cookie.

Would they manually set开发者_Go百科 it in their browser? If so, wouldn't a website reject a cookie it didn't set? Do attackers write a custom script to manually send whatever malicious HTTP requests they desire and set the malicious cookie first?

Just curious....

This isn't really about XSS at all. The topic you are referring to is called session fixation or session hijacking.

If so, wouldn't a website reject a cookie it didn't set? 

HTTP is stateless. It doesn't remember which cookies it gave to which people.

Sessions are implemented differently by different runtimes (e.g. PHP versus JSP), but the general principle is the same. Session data is stored on the server and identified by a unique, hard-to-guess key. This key is shared with the client on the initial request if the request doesn't contain one already.

Sometimes the key is transferred as a cookie, which is convenient because the client will generally always send cookies automatically. But the session ID can be passed in other ways, as well, such as in the query string. For example, you see many websites that have URLs like this:

http://jksiusjkakek.com/path/to/app?SESSIONID=1jk98s9sji29sk2lui2

This is generally not a good thing to do, because it means the session ID gets captured in any bookmarks created or links sent to other people, making session fixation much easier.

Do attackers write a custom script to manually send whatever malicious HTTP requests they desire and set the malicious cookie first?

If the site passes the session ID in the URL, like I showed above, then it's easy: the attacker just copies/pastes the session ID into the URL string.

If the site passes the session ID as a cookie, then the attacker will need to manually set a cookie on his own browser. The easiest way to do this would be to literally open up your cookie preferences window and manually copy/paste the session ID into a new cookie...

Although I'm sure real bad guys have even more efficient ways than that :)

XSS is about more than just stealing cookies.

That said, many sites and applications store a reference to the server side session in a cookie variable (such as a JSESSIONID in Java). If XSS is used to store this value, an attacker may be able to forge your session and take it over, pretending to be you. This is sometimes called Cross-site Request Forgery. Imagine if you didn't click the "log off" button in your online banking session, then the stolen cookie value allows the attacker to resume your session from his computer, transferring money out of your account.

In some cases, they inject XSS to forward you to a site that appears to be the valid site, but the site itself is a forgery. Then, this site can phish for your personal details or credit card numbers, all the while you are thinking you're still on a legitimate site.

Some XSS attacks may be just annoying, consuming massive resources, crashing your browser, or perhaps just popping up SPAM ads, etc.

XSS could also be used to scrape other information from the current browser window, and transmit it to a location the attacker has access to. Imagine a data element that has an XSS injection, but on the same screen there is also your account number.

Check out owasp.org for more info. Their top 10 is essential for any web developer. I tell my developers, if you've coded an application, you've probably coded some vulnerabilities. Knowledge is power here. Memorize and understand the OWASP top 10, and you'll be in better than average shape.

Ok besides cookie stealing, session hijacking etc (which has been covered fairly extensively) here, XSS actually can be now a days used in so many more ways, especially when it comes to persistent XSS (in most simple terms XSS that is saved by the server and served by the server to a user without attacker intervention). You can replace the content of the whole page to phish for plain text passwords, you can spread web worms, you can use pretty much any functionality of the web application, such as sending messages, posting posts... which again can be used in numerous ways from spreading malware to simple pranks. Lastly new innovations in HTML5 will make persistent XSS even more dangerous, you will actually be able to completely hijack the website in question, including url bar, so user won't actually ever leave your control and you can log anything user does (and with resource origin sharing even everything user sends) very easily with rising little to no suspicion, even complete key logging as far as browser window of that particular website could be used. Think google analytics but malicious...

Those are just few examples that XSS is not solely about cookies and sessions, now a days it presents (unfortunately) wider and wider possibilities of malicious usage.