Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I think it definitelly isn't, because XSS which isn't saved anywhere would damage ONLY attacker.

Am I right or are there any cases where XSS could hurt non-db-application? (I mean datas are not saved anywhere)

share|improve this question
add comment

4 Answers

up vote 22 down vote accepted

Very wrong, the basic form of XSS is Reflected XSS, where the payload is sent in the URL (for example) from the victim himself.
This is most commonly used in phishing attacks, where the attacker crafts the malicious link, and mails it in social engineering attacks to his victims, or posts it on public forums, etc.
In general XSS has nothing to do with database (unless it's Persistent / Stored XSS).

See XSS on OWASP for more details.

share|improve this answer
    
A website without a database has no credentials, so I still don't see how XSS could be dangerous. –  BlueRaja - Danny Pflughoeft Jul 25 '11 at 18:52
3  
@BlueRaja, your statement has two misconceptions: (1) a database is the only way to store credentials, (2) and stealing credentials is the only danger of XSS. A better way of looking at XSS would be: Misusing the trust a user has for a website. In other words, even if there are no credentials, an attacker could use XSS to do anything the user allows the site to do: run scripts, modify the page, provide information, redirect to other sites, etc. –  AviD Jul 25 '11 at 20:02
add comment

A good example of the dangers of XSS with or without a database attached can be seen from the BEEF Project. This shows some of the things that can be done to a users browser once it's been affected by a XSS issue.

If you look at the youtube videos on this page there's some good examples of what can be done.

share|improve this answer
add comment

I figure that if XSS is a vulnerability, the next step is to look at code injection. Let's use SSI for example. If this works:

<javascript>alert('x');</javascript>

Then it's possible that this would work also:

<!--#exec cmd="ls /" -->

No matter what, you should sanitize your input.

More on SSI injection here.

share|improve this answer
3  
Are you sure this is right? I thought SSI was done before scripting (perl, php, etc.) so you could only affect output to the user. –  freddyb Jul 28 '11 at 12:29
add comment

There are many ways XSS can exploit and do much damage without it having to be stored in a database. Remember that the XSS can even be stored in cookies!

However if you are only talking about non-persistent- reflected-XSS it is still very dangerous, but more from a social engineering point of view. This is because you have to actually distribute the XSS payload instead of it spreading on its own. Means of distribution of the payload can be for example:

  • Emailing suitable victims
  • Posting the URL on forums, boards, twitter. Often with the help of URL shorteners
  • On memory sticks. for example disguising XSS in the readme files of a program you give away for free on an USB stick.
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.