2

Background:

I've been searching for a way to sanitise some form inputs with JavaScript to prevent the form being submitted if it contains characters that aren't whitelisted.

I've come up with this based off a brilliant Stack Overflow answer

function allowSubmission(string) {
    return string == string.replace(/[^\w\s]/gi, 'X');
}


var s1 = 'simple string';
var s2 = 'alert(0);';
var s3 = '<nasty>string';

console.log(allowSubmission(s1)); //true
console.log(allowSubmission(s2)); //false
console.log(allowSubmission(s3)); //false

Problem

But doesn't this just mean a potential attacker can turn off JavaScript and submit whatever the hell they like? Or simply edit the JavaScript on the fly and overwrite the validation method to just return true.

Question

SO... Isn't input sanitisation with JavaScript pointless?

Community
  • 1
  • 1
Luke
  • 3,481
  • 6
  • 39
  • 63
  • 1
    Input should always be sanitized on the server side if you want to enforce that it's sanitized. – Dave Newton Mar 11 '14 at 18:05
  • 1
    do not confuse sanitization with validation. – zzzzBov Mar 11 '14 at 18:06
  • This is a good question, but it's important to note that validation and sanitization are two different things. – Jordan Running Mar 11 '14 at 18:07
  • Thanks Everyone :). I guess I'll leave it in place for usability purposes, so i can let users know that it isn't going to submit correctly and then re-sanitise the inputs server side. – Luke Mar 11 '14 at 18:10

3 Answers3

10

This only means you should always validate and sanitize your input server-side. Regardless of whether it's checked in front-end as well.

Doing this in JavaScript can help you avoid unnecessary requests hitting your backend and increasing the load as well as improve the user experience but they should not be treated as a means of security.

It's pointless, when treated like a line of defence. In general, its use serves many purposes.

toniedzwiedz
  • 17,895
  • 9
  • 86
  • 131
  • Actually, in a way, it is a line of defense is the sense that you now know that your normal clients CANNOT send you crap data. So if you receive total bullshit you know that a hacker sent it. Without any sanitisation, you cannot be sure whether a normal client or a hacker sent the data. That being said, it is correct that the server MUST also check the data because it can always be tainted. – Alexis Wilke Mar 11 '14 at 21:55
3

But doesn't this just mean a potential attacker can turn off javascript and submit whatever the hell they like? Or simply edit the javascript on the fly and overwrite the validation method to just return true.

Yep, but that doesn't make javascript validation pointless.

The purpose of javascript validation is not to sanitize input for the server. That job must be handled by the server.

The purpose of javascript validation is to make the user interface more responsive for the user. JavaScript validation allows the user to know when they made a mistake without having to wait for a potentially slow server response. It can also reduce the overall load on the server.

Client-side JavaScript should never be used as the only means of sanitizing input, it can be used to assist the server, but in the end the server must be able to correctly handle invalid input.

zzzzBov
  • 174,988
  • 54
  • 320
  • 367
2

Input sanitization is not done for security, but for usability. You should give feedback to the user that he inputs bad characters as soon as possible (on each keystroke), not after he submits the form and the response comes back from the server.

For security you MUST validate anything coming from the client on the server. There is no way around it.

Tibos
  • 27,507
  • 4
  • 50
  • 64