As discussed in Part 1 or this blog post, too many companies wait until after a data breach has occurred until online security becomes a priority. With daily instances of small and large-scale hacks, it’s odd that many still maintain the “it won’t happen to me” attitude until it happens to them.
An effective approach to website security must be proactive and defensive. The idea here is to inject the reader with a healthy dose of paranoia so that website security measures can be taken now. Here are the final five vulnerabilities:
Common Mistake #6: Sensitive data exposure
This web security vulnerability is about crypto and resource protection. Sensitive data should be encrypted at all times, including in transit and at rest. No exceptions. Credit card information and user passwords should never travel or be stored unencrypted, and passwords should always be hashed. Obviously, the crypto/hashing algorithm must not be a weak one. And while it goes without saying that session IDs and sensitive data should not be traveling in the URLs and sensitive cookies should have the secure flag on, this is very important and cannot be over-emphasized.
Prevention:
- In transit: Use HTTPS with a proper certificate and PFS (Perfect Forward Secrecy). Do not accept anything over non-HTTPS connections. Have the secure flag on cookies.
- In storage: This is harder. First and foremost, you need to lower your exposure. If you don’t need sensitive data, shred it. Data you don’t have can’t be stolen. Do not store credit card information ever, as you probably don’t want to have to deal with being PCI compliant. Second, if you have sensitive data that you actually do need, store it encrypted and make sure all passwords are hashed.
And at the risk of stating the obvious, do not store the encryption keys next to the protected data. That’s like storing your bike with a lock that has the key right next to it. Protect your backups with encryption and keep your keys very private. And of course, don’t lose the keys!
Common Mistake #7: Missing function level access control
This is simply an authorization failure. It means that when a function is called on the server, proper authorization was not performed. A lot of times, developers rely on the fact that the server side generated the UI and they think that the functionality that is not supplied by the server cannot be accessed by the client. It is not as simple as that, as an attacker can always forge requests to the “hidden” functionality and will not be deterred by the fact that the UI doesn’t make this functionality easily accessible. Imagine there’s an /adminpanel and the button is only present in the UI if the user is actually an admin. Nothing keeps an attacker from discovering this functionality and misusing it if authorization is missing.
Prevention: On the server side, authorization must always be done. Yes, always. No exceptions or vulnerabilities will result in serious problems.
Common Mistake #8: Cross Site Request Forgery (CSRF)
This is a nice example of a confused deputy attack whereby the browser is fooled by some other party into misusing its authority. A third-party site, for example, can make the user’s browser misuse its authority to do something for the attacker.
In the case of CSRF, a 3rd party site issues requests to the target site (e.g., your bank) using your browser with your cookies / session. If you are logged in on one tab on your bank’s homepage, for example, and they are vulnerable to this attack, another tab can make your browser misuse its credentials on the attacker’s behalf, resulting in the confused deputy problem. The deputy is the browser that misuses its authority (session cookies) to do something the attacker instructs it to do.
Fun fact: CSRF is also the method people used for cookie-stuffing in the past until affiliates got wiser.
Prevention: Store a secret token in a hidden form field which is inaccessible from the 3rd party site. You of course always have to verify this hidden field. Some sites ask for your password as well when modifying sensitive settings (like your password reminder email, for example), although I’d suspect this is there to prevent the misuse of your abandoned sessions (in an internet cafe for example).
Common Mistake #9: Using components with known vulnerabilities
The title says it all. I’d again classify this as more of a maintenance/deployment issue. Before incorporating new code, do some research, possibly some auditing. Using code that you got from a random person on GitHub or some forum might be very convenient but is not without risk of serious web security vulnerability.
I have seen many instances, for example, where sites got owned (i.e., where an outsider gains administrative access to a system), not because the programmers were stupid, but because a third-party software remained unpatched for years in production. This is happening all the time with WordPress plugins, for example.
The lesson here is that software development does not end when the application is deployed. There has to be documentation, tests and plans on how to maintain and keep it updated, especially if it contains 3rd party or open source components.
Prevention:
- Exercise caution. Beyond using caution when using such components, do not be a copy-paste coder. Carefully inspect the piece of code you are about to put into your software, as it might be broken beyond repair (or in some cases, intentionally malicious).
- Stay up-to-date. Make sure you are using the latest versions of everything that you trust and that you have a plan to update them regularly. At least subscribe to a newsletter of new security vulnerabilities regarding the product.
Common Mistake #10: Unvalidated redirects and forwards
This is, once again, an input filtering issue. Suppose that the target site as a redirect .php module that takes a URL as a GET parameter. Manipulating the parameter can create a URL on targetsite .com that redirects the browser to a site like malwareinstall .com. When the user sees the link, they will see targetsite .com/xoxoxo which the user thinks is trusted and is safe to click. Little do they know that this will actually transfer them onto a malware drop or another malicious page. Alternatively, the attacker might redirect the browser to a site like targetsite .com/deleteprofile?confirm=1.
It is worth mentioning, that stuffing unsanitized user-defined input into an HTTP header might lead to header injections.
Prevention: Options include:
- Don’t do redirects at all (they are seldom necessary).
- Have a static list of valid locations to redirect to.
- Whitelist the user-defined parameter, but this can be tricky.
Age-old software practices exist for a reason and what applied back in the day for buffer overflows, still apply for pickled strings in Python today. Online security helps you write safe and correct programs, to which all programmers should aspire.
In Part 1 of this post, we uncovered five more vulnerabilities. Be sure to read about them here, as having half of the story is a lot like protecting half of your website.
To receive malware and vulnerability scanning of your site on a daily basis from an approved scanning vendor, contact Trust Guard or click here.
Special thanks to Gergely Kalman, a security specialist at toptal.com/security for his article on the same topic and from which much of the information for this article was utilized.
Leave a Reply