Written by Varghese George
Mr. Varghese is the Senior Manager for Technology Services Division providing the best of Back-up and Security Solutions to our clients.
For many companies, best practices in web security become a priority only after a security breach has occurred. A practical approach to web security threats must be proactive and defensive by definition. This post is intended to spark a security mentality and hopefully, inject a healthy dose of paranoia into the reader.
This guide focuses in particular on common and significant pitfalls about web security, including recommendations on how to mitigate them.
I often encounter confusion about the distinction between authorization and authentication when speaking with other programmers and IT professionals.
So let’s clarify the distinction between these two terms:
Authentication: Verification that a person is (or at least appears to be) a specific user since he/she has provided his / her security credentials correctly (password, answers to security questions, fingerprint scan).
Authorization: Confirming that a user has access to a specific resource or is authorized to carry out a particular action.
In other words, authentication knows who an entity is while authorization knows what an entity can do. Let's get into the internet security problems with that in mind.
Web Security Mistake 1: Injection Flaws
A classic mistake to filter untrusted input results in injection defects. It occurs when unfiltered data is passed to the SQL server (SQL injection), the browser (XSS), the LDAP server (LDAP injection), or elsewhere. The attacker can inject commands into these entities, resulting in data loss and the removal of browsers from customers.
Anything received on your application from an untrusted source must be filtered, preferably according to a whitelist. It would be best if you seldom used a blacklist because it is complicated and usually easy to circumvent. Antivirus software products typically offer stellar examples of blacklists that fail. Pattern matching usually doesn't work.
Prevention: The good news is that injection protection is "simply" a matter of adequately filtering your input and considering whether an input can be trusted. Since filtering is quite tricky to do (such as crypto), I usually recommend relying on the filtering functions of your framework: They have been proven to work and thoroughly screened. If you don't use frameworks, you need to think about whether it makes sense to use them in the context of server security.
Mistake 2: Broken Authentication
This is a collection of several problems that may occur during broken authentication, but they all don't stem from the same root cause. If anybody wants to roll their own authentication code, I advise against it. Getting it right is extremely difficult, and there are many myriads of possible pitfalls, to mention a few:
The URL could contain the session ID and leak it to someone else in the referer header.
Passwords in storage or transit may not be encrypted.
The session IDs may be predictable, making it trivial to gain access.
Fixing the session could be possible. Hijacking sessions may be possible, timeouts not implemented correctly or using HTTP (no SSL security).
Prevention: Using a framework is the simplest way to avoid this vulnerability in web security. You may be able to do this properly, but the former is much more comfortable. Be extremely vigilant and educate yourself on what the pitfalls are if you want to roll your own code.
Mistake 3 : Cross Site Scripting (XSS)
An attacker provides input tags for your web application JavaScript. If this input is returned unsanitized to the user, it will be executed by the browser of the user. It might be as easy as inserting a link and persuading a user to click on it, or it can be much more sinister.
Prevention: There is a simple solution for web security: do not return to the client HTML tags. This has the added advantage of defending against HTML injection, a similar attack by which the attacker injects annoying plain HTML content (such as images or loud invisible flash players)
Mistake 4 : Insecure Direct Object References
In a resulting security vulnerability, this is a classic case of trusting user input and paying the price. A reference to a direct object means the exposure of an internal object such as a file or database key. The concern is that the attacker can provide this reference and if the authorization is not enforced correctly or is broken, the attacker can access or do things to prevent them from doing so.
Prevention: Perform user authorization consistently and adequately.
Mistake 5: Security Misconfiguration
Web servers and applications are way more common than those that have been appropriately configured. Some examples:
Running the application in production with debugging enabled.
Having unnecessary programs running on the machine.
Default keys and passwords are not changed.
Prevention: Have a good "build and deploy" process (preferably automated) that can run tests on deployment. Post-commit hooks are the security misconfiguration solution for the poor man, to prevent the code from going out with built-in default passwords and development stuff.
Mistake 6: Sensitive data exposure
This vulnerability to web security is about the protection of cryptography and resources. Encrypt sensitive data at all times. There's no exception. Credit card and user password information should never be traveling or stored unencrypted, and passwords should always be hashed. Sensitive information should not travel in URLs and keep the secure flag on for sensitive cookies.
Prevention: Use HTTPS and PFS (Perfect Forward Secrecy) with a proper certificate. Have the secure flag on cookies
Mistake 7: Unvalidated redirects and forwards
This is again a problem of filtering inputs. Suppose the target site has a module redirect.php which takes a parameter URL as a GET. Manipulating the parameter can create a URL that redirects the browser to malwareinstall.com on targetsite.com. The user targetsite.com/anbdhrnm which the user confuses for a trusted link and assumes safe to click. As soon as they click on this link, they will be transferred to a malware drop page.
Prevention: Don’t click redirects at all (they are seldom necessary). Have a list of valid locations to redirect to.
HTTPs, ITsecurity, Online, SSL, Sucurri, Websecurity,
5 mins read
The digital world is transforming at an unprecedented rate. With the advent of new technologies, devices, and platforms, we're witnessing a surge in convenience but also an...
Start Reading
3 mins read
Ethical hacking or white-hat hacking, is the legal act of bypassing application, system, or infrastructure security controls to identify breaches and put the defenses to th...
Start Reading