PrestaShop 1.4
Child pages
  • Accelerated Security Course - Episode 3 - XSS

Versions Compared

Old Version 3

changes.mady.by.user Xavier Borderie

Saved on

compared with

New Version Current

changes.mady.by.user Xavier Borderie

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Accelerated Security Course - Episode 3: XSS

This article was written by Damien Metzger, and first published on the PrestaShop blog, on September 28th, 2011.

It would be wrong to assume that you need to access a website’s code to be able to hack into it. In fact, even at the HTML display level, you need to protect all data that appears.

An XSS flaw involves exploiting the browser’s interpretation of HTML/Javascript when displaying data. If you display any unprotected data in the page – that is, without taking care to convert the characters that are being interpreted - the browser will be able to interpret the variables that are displayed as HTML or Javascript.

Tip

Example.

Page :

Code Block
<html> <body> No results were found for the keyword $keyword.</body> </html>

Exploitation :
You just need to enter the following character chain as a keyword:

Code Block
<script type="text/javascript">alert('kikoo');</script>

Result:
A "kikoo" alert will appear on the page.

Of course you can do much more in Javascript than just add an alert, such as redirect the user to another website, steal cookies and more.

How can you protect yourself?

This is not very complicated: everything that appears in your HTML pages must be protected with a function like htmlspecialchars() or htmlentities(). In some cases you may also use additional functions such as strip_tags() which removes all HTML tags from a character chain, or a simple addslashes() if you are working in Javascript.

The real difficulty is therefore not protecting yourself, but remembering to do so. The main reasons for forgetting this are:

  • The amount of variables involved. An enormous amount of variables are displayed to users, and all it takes is a "well-placed" one to enable hackers to exploit an XSS flaw.
    In the same vein, when you are designing the website you need to think about when you are going to protect these variables. Directly in the template to get it done early on? This is rather ineffective and inefficient. In the checkers? It’s easy to forget to check them all. In the view? If you consider that security is a developer’s job, then maybe. And of course, doing it at several levels is out of the question, as you cannot accumulate these protection functions or you will end up with an illegible result. There is no quick fix for this issue: each page must be systematically checked as everyone is involved in this.
  • The type of variables involved. XSS does not only affect POST or GET data! For example it is very easy to forge a referrer to exploit an unprotected "previous" button. Your database is perhaps not as secure as you think: security can be compromised by a deliberate attack, or because you have accidentally used interpreted characters (this won’t be an XSS but the display will be broken).
    In short: no data must be left out, as no data is completely reliable.