tags:

views:

599

answers:

6

I am creating a webpage where the user can interact and perform basic filesystem operations(create file/dir, delete file/dir, navigate filesystem) on a remote computer. The webpage is basic HTML(UTF-8 encoding) and Javascript. I need to make this webpage XSS proof.

Would escaping all non-alphanumeric chars in user input(to protect against DOM based XSS) and filename info(to protect against stored XSS) using Javascript(this outputs percent-encoded hex values) suffice?

I am essentially whitelisting only the alphanumeric input. Also, since I am using percent encoded hex values, I am assuming the UTF encoding vulnerability should not be present.

Can anyone think of any security loophole in this mechanism?

A: 

This sounds secure, and probably is, but there is a catch. It only works if you implement it correctly. It's just way too easy to get wrong. If you want to go for it, that's okay, but I would suggest using some already tested libraries to do this, rather than rolling your own.

Zifre
A: 

Encoding is good to do. The biggest potential risk is what you do with the data and if/when the data is decoded/displayed. If you decode the user input and display it, decoding the data, then you may have issues at that point.

If you have no pressing need to support characters that are more risky in terms of potential XSS vulnerabilities (such as '<', '>', ';', etc.) then I think it is reasonable to blacklist those characters as well. That way, in the event you decode and display data, you won't potentially express an XSS issue.

Demi
+7  A: 

Using javascript (Which is what I think is you're saying) to do the escaping doesn't seem too secure. It runs on the users machine and they could, with some effort bypass the escaping mechanism.

What you're trying to do sounds right, but you need to do it server-side.

Alo
A: 

The basic way to defend against XSS is to use regular expressions to validate input whenever possible and to encode all output. Encoding output can be tricky, so it is best to use a library. Tt least one important input to your application is filenames, so you would want a regular expression that would match any valid filename for your target OS. Accepting only alphanumeric input would make it impossible for your app to handle many filenames on common operating systems. I don't follow why using %hex values would do any good. There's no reason a malicious script can't be encoded that way. The same script can have many valid utf-8 representations. You need to do some more background reading on anti-XSS coding practices. Google OWASP for references.

dontcallmi
+1  A: 

A few point of note:

  • As @Alo said, this should be done server-side, to prevent an attacker from bypassing your javascript altogether and sending the malicious input directly to the server. However, as you noted, this should be done (in certain situations) ALSO on the client-side, to prevent DOM-based XSS.
  • You mentioned that the page is UTF-8, you need to enforce this using meta tags, HTTP headers, etc. Otherwise, you're vulnerable to UTF-7 attacks.
  • Spaces - is that conisdered alphanumeric, or not? (some include that...) Using just a space and letters, a fullblown XSS attack CAN be mounted, in some situations.

Check out some more info in my answer to Will HTML Encoding prevent all kinds of XSS attacks? You'll find all you need to know there.

AviD
+1  A: 

A note to supplement other points made:

Make sure you are using GET and POST correctly, because that is the simplest kind of security hole on many websites.

If user input is going to trigger any change to the database, make sure you use POST.

Only user GET if you are retrieving information to be displayed.

ghills