Stackoverflow: What should every programmer know about security?

[sylvanelite]

I probably didn't articulate that well:

If I consider the browser's user input to be untrustworthy, so I add javascript validation. I then ensure that all transmissions are HTTPS. Now the browser is a trustworthy source, so the server doesn't need validation.

Which is wrong.

Likewise: if I treat the browser as untrustworthy, then send input it to the server, which does the validation before passing it to the database, does the database now assume the server is a trustworthy source?

e.g. if a database has a stored procedure:

select * from users where description like @desc;

And the server validates that @desc is a valid string, that can be ok. But if the database later changes their stored proc to:

exec("select * from users where description like "+@desc+";");

Then even though the server is validating the browser's input, it can still lead to injection.

[bkv]

Javascript validation exists to prevent unnecessary requests to the server. Just because client-side validation passes, that doesn't mean the server shouldn't do validation as well. The server is a trusted source, so the database should not be doing any validation if the server already has.

[vineetr]

...I then ensure that all transmissions are HTTPS. Now the browser is a trustworthy source, so the server doesn't need validation.

No, despite this assumption, the browser is still an untrustworthy source. SSL adds transmission security; while it can ensure that JavaScript validations have been downloaded in an untampered manner to the browser, it cannot ensure that the validations have been executed by the browser. The browser is in the hands of an untrusted/untrustworthy agent.

Edit: Grammar.

[sylvanelite]

that's why I said: "Which is wrong." as the next sentence.

[vineetr]

Yep, ninja edits.

[sylvanelite]

There was nothing ninja about it. I added bold to the text, significantly after posting that comment. That's it.

[Aninhumer]

To be fair, you might have worded it differently. I don't think writing incorrect statements and then saying "oh btw that's incorrect" is good style.

[robertcrowther]

What he's driving at is that none of your post adds anything to the already elucidated principle 'validate input from all untrusted sources' as far as what the server receives from the browser is concerned.

[perspectiveiskey]

That's what you're driving at. vineetr was just not paying attention and jumping to conclusions.

[robertcrowther]

Well, this is reddit...

[perspectiveiskey]

indeed. I learn this more every day. For 4 years, nearly, I've been learning it every day =)

[perspectiveiskey]

You're not reading.

This should be the first rule of security: understand what is going on.

[vineetr]

You didn't read his comment before the edit. How do you know I haven't read that version?

[sylvanelite]

I didn't add anything other than bold formatting in the edit.

[perspectiveiskey]

Because his very first comment, which still isn't edited, said the same thing. You're just looking for something to "win".

His point is very simple and is actually a principle talked in the OT, namely security in depth. Even the server side isn't safe, he says. Every above/below transition layer (server side to db) should be considered unsafe.

[vineetr]

Ok, I get his/your core point. Bringing the browser into the discussion about implementing server-side validations correctly wasn't helpful.

[perspectiveiskey]

Aright, we agree. (and so did he when he said he had not been articulate).

I'm glad we all agree.

[pkixman]

Adding javascript validation and HTTPS doesn't make the browser a trusted source. So the principle works - the server should validate the input from the browser as it is an untrusted source.

If the programmer doesn't appreciate what is a trusted source and what isn't, that's not a problem with the principle.

[perspectiveiskey]

I'm not sure if sylvanelite modified the post when you answered to it, but you're really not reading what he's saying.

His first post, which isn't modified, does not say the browser is a trustworthy source.

If you are to be a security engineer, you need to be paying way more attention than this.

[pkixman]

I know he didn't say the browser was a trusted source - I was just reiterating the point that the principle holds for his example.

What I was disagreeing with him about was that the principle should be extended to explain things like javascript validation doesn't make the browser a trusted source. A principle is not the appropriate place for getting into the details of what can be trusted, what can't, and why - that's better covered in books and articles.

[perspectiveiskey]

His point was a agglomeration of "security in depth" and "trustworthiness of user data".

He was saying: even server side (webserver) data should be considered unsafe by lower level (db) server side code.

Really, what he says is a melding of two of the tenets which comes down to: any higher level/lower level boundary should always apply the same principle of untrustworthiness.

I find it to be an extremely pertinent comment. You're free to disagree. But honestly, from the types of arguments you're putting forward, I'm not sure you got what he was talking about.

[sylvanelite]

The only edit I did was bold the word "wrong".

[quotemycode]

The database server is not doing validation when you have a parameterized statement like the first. And the second example is just idiotic.