0

I read about XSS attacks and its prevention mechanism on server-side. It seems only protection is to sanitize the input by escaping special characters on server side (Using some PHP functions such as htmlspecialchars() ). I have read this here. So now suppose some input like 3<2hello 4>3 or something like that. This is not harmful but it will be escaped. So is this a false positive of the protection? Or there are some more sophisticated protection against XSS on server side?

Improve this question

1 Answer 1

Reset to default
1

First, what htmlspecialchars() and similar functions do isn't removing dangerous code, it's encoding data as HTML.

So, what htmlspecialchars does not do is the following:

  • Receive data
  • Find dangerous HTML code and replace this by harmless code
  • Return the sanitized data

But it does the following:

  • Receive data
  • Convert this data to HTML, so that when this code is displayed it will look the same as when the original data would be viewed without being parsed by an HTML parser.
  • Return the HTML code

➥ You can see the difference here

Additionally, since you're asking this, you may be misunderstanding where XSS prevention should be applied. Encoding data as HTML shouldn't be done when it is received, but when it is outputted by the web server.

So, you should not be doing it like this:

  • Server receives data from a client
  • Server escapes the data as HTML
  • Server processes the data
  • Server outputs the data to the client

But like this:

  • Server receives data from a client
  • Server processes the data
  • Server escapes the data as HTML
  • Server outputs the data to the client
Improve this answer
5
  • First of all, I don't understand the difference between two. Can you elaborate? And I wanted to say escaping all special character will incur escaping harmless input.
    – Naman
    Commented Mar 4, 2014 at 9:21
  • @Naman I've improved my answer. Let me know if it helps.
    – user2428118
    Commented Mar 4, 2014 at 10:23
  • Yes, It helped. thanks. It means there is no protection which identify that this a harmful input, so only this should be encoded?
    – Naman
    Commented Mar 4, 2014 at 10:32
  • @Naman I'm not entirely sure what you're asking, but what htmlentities does is taking data and generating HTML that, when parsed as HTML, will show the same data that htmlentities received. (Okay, to get it to look exactly the same you would have to style the resulting HTML with font-family: monospace and white-space: pre or wrap it in a <pre> tag.)
    – user2428118
    Commented Mar 4, 2014 at 10:40
  • 1
    +1. There is no such thing as harmful input, only input that isn't handled correctly. Trying to address XSS by filtering “bad” things at the input layer is a deeply mistaken strategy that can never fully work; the correct approach is to handle the data correctly: here, by HTML-escaping content you put into HTML; and similarly JS-escaping content you put into JS, and so on for every different kind of context. There is certainly a place for input validation, and you'll definitely want to do it for business-logic purposes, but it is not your primary defence against injection attacks.
    – bobince
    Commented Mar 4, 2014 at 12:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .