9 comments

[ 3.2 ms ] story [ 40.1 ms ] thread
This long-form article, I discussed in details how to prevent SQL injections, Cross-site scripting, and file upload attacks in web applications. I brought together my 10+ years experience with Linux server administration and 4+ years experience with full-stack software development to draft one of the most detailed post on the subject matter on the internet. I'm looking forward to your feedback.
Honestly, I wouldn't even suggest people try and escape their inputs. Just use parameters. They will be far more secure than attempting to escape and sanitize inputs.
I agree as well. I suggested using parameters/bindings. Hope you saw that in the article. Thank you for your comment.
I did see that, I was saying skip the first suggestion of sanitizing input, and just use the second suggestion. The first suggestion is just asking for trouble.
This advice doesn't sit right with me. I like to make sure my numbers don't contain chars. But that is about not breaking my data flow- not security.
Sure, I'm not talking about no validation or sanitation. I'm talking about as a security measure. Trust the far more secure parameters rather than thinking that escaping some quotes is going to protect you.
That's the purpose of validation. I think we was talking about sanitisation before storage. But I think that if there is a good validation, sanitisation is half taken care of. Sanitisation will still be indispensable even if one is using parameter bindings or prepared statements.
> So the company value will be stored like this: ' or '=' instead of this " or ""="

No, if they enter '"', store it as '"' in your database (maybe by using '\"' in the query), serve it as ''' in html ('"', actually).

Yes, you should persist the raw user input. Why would my non-html gui app show some escaped html?