Beyond SQL injections and XSS

Question

I'm a programmer working on a web service (by myself). Given the fact that I am not a security expert, I came to this website to ask my question.

I did all the major things to secure my website. I tried to protected against...

1. SQL injections by using prepared statements.
2. XSS Attacks by using json_encode(htmlspecialchars($str)); when sending users' string inputs (all my data is sent via JSON).
3. Password compromises by using the following function to encrypt passwords:

[I found this online but should I use bcrypt instead of crypt?]

$cost = 10;
$salt = strtr(base64_encode(mcrypt_create_iv(16, MCRYPT_DEV_URANDOM)), '+', '.');
$salt = sprintf("$2a$%02d$", $cost) . $salt;
$password = crypt($pass, $salt);

And then to log in:

if (crypt($pass, $realpass) == $realpass)
{ //$pass = entered password, $realpass = database
    //yay
}

In addition, there are a number of things on top of my head that I did not account for. These include:

1. Uploading to server - can images/videos be malicious if edited with imagick/ffmpeg?
2. Legality - How to sanitize illegal content (i.e. child porn, etc.) or even illicit content (i.e. nudity)?

I also didn't worry about command/code injection since I don't have any executions vulnerable to those. Oh and, of course, I'm sending/receiving everything over HTTPS.

HOWEVER, I'm sure all of you are sitting there at home laughing at my stupidity in the subject. Security experts are not paid a salary to, you know, secure against things as elementary as SQL injections. I seriously doubt that any major security breaches occur because of any of the potential security breaches I listed above.

And so my question is, what am I missing? It's worth noting that I'm going to use AWS's EC2, hence I don't know if I need to take extra security measures to the server or not.

Thanks in advance.

Answer 1

I seriously doubt that any major security breaches occur because of any of the potential security breaches I listed above.

It sounds like you are covering these well known vulnerabilities that are due to insufficient parameter sanitization, so you would expect the rest of the world did so as well.

But, boy, you would be wrong!

According to the results of a recent survey of 595 U.S.-based IT security practitioners, 65 percent of respondents said their companies had experienced SQL injection attacks that successfully evaded their perimeter defenses in the past 12 months.source

and XSS is by far the most common vulnerability according to The WhiteHat web security report

What are you missing?

File Uploads I think this 8 basic rules for secure file uploads by SANS is excellent.

Third Party Libraries Your code could be perfect but rely on insecure third party libraries for all sorts of functionality. These take work to keep up to date with the latest patches.

Privilege Escalation Most of the applications I test, after their parameters are all well sanitized, haven't paid attention to privilege escalation. This is a type of vulnerability that automated scanners are not very good at detecting. For example, many applications populate forms with choices based on the privilege of the user. A malicious user can add choices to these forms on the client side with great effect unless the server is wise to what the user should be allowed to do. Some web frameworks control this much better than others.

Logging Make sure security related events are captured somewhere so that you can know what is going on. Events to capture: succesful logins, failed logins, role changes, file uploads, file downloads, database errors, and any more that are important to you.

Answer 2

Since you are building a web-application a good place to start is the OWASP Top Ten.

Once you believe that you've done well to harden your code look into doing both static and dynamic analysis on it.

Static analysis tools will vary according to the framework your using. Again, OWASP can get you started.

After that, check the Terms of Service for AWS and run a vulnerability scanner against your web app. OWASP ZAP is a nice, easy tool for this.

Having completed these steps you will be well on your way to having a more secure web application.

Answer 3

In addition, there are a number of things on top of my head that I did not account for. These include:

Uploading to server - can images/videos be malicious if edited with imagick/ffmpeg?

Not with that, but they can be harmful in two ways:

• harmful to you. If the image being uploaded is actually executable code, and the server can be tricked into executing it, or if the save path is under the user's control and he can overwrite some critical file with a maliciously-named JPEG. You can prevent this by:
  • checking the image's type when it is uploaded (possibly stripping it of EXIF/APP data).
  • saving it with a name of your choice, and better still, a unique ID; then you can save the user's original name; when the user asks for the image you can send it as an attachment using the original name, but on the server the file has not even an extension, and is not executable in any way.
• Harmful to others: you can create a JPEG that requires several gigabytes of RAM to be fully represented. Then send the link to the JPEG itself. You can check this - I see you are coding in PHP - by using getImageSize(), which does not decode the image and hence consumes very little memory.

Legality - How to sanitize illegal content (i.e. child porn, etc.) or even illicit content (i.e. nudity)?

Some image formats allow embedding a "rating" tag, but if you can't trust it (or there is no tag to begin with), I'm afraid you're out of luck. There are some online services that rate a picture based on feature extraction, but there are considerations of cost, bandwidth, efficacy. Get a look here. There also was a question on Stack Overflow.

HOWEVER, I'm sure all of you are sitting there at home laughing at my stupidity in the subject. Security experts are not paid a salary to, you know, secure against things as elementary as SQL injections.

You'd be surprised...

I seriously doubt that any major security breaches occur because of any of the potential security breaches I listed above.

...and now you're making me cry. I'm not trying to be flattering or ingratiating, but the sad, sad truth is that lots of highly paid developers and project heads do not really think out, implement, and test one tenth of what you've 'considered' on your own. Security seems to have no ROI, or as Joel said, it's submerged. Easy to overlook. Due to time-to-market and budget constraint to be sure, it's not as if they wouldn't do it if they could. Still, I could easily name several large sites, one of which part of a project costed in the millions, where little Bobby Tables had a permanent admin-level entrance. One where the "security" of the admin control panel was assured "by the fact that the URL had to be typed manually". And I'd bet dollars against peanuts that most developers out there have a pet horror story of their own.