Web Security Risks
OWASP’s famous Top Ten guide as a starting point
Vespa
OWASP is a much friendlier bug than their fellow Vespa that’s been in the news these days, the “murder hornet”. 2020 is really giving us all it can, isn’t it?
The Open Web Application Security Project is a non-profit organization that operates around the world to help improve online security, especially by educating of those of us who build and maintain those applications. Their famous Top Ten list is a great starting point to get a sense of how companies fail in meeting their (and their users’) security needs, so that the rest of us can learn what to avoid. They range from obvious to obscure, from the details of technical work to the culture of business practice. Let’s take a look:
Security Misconfiguration
Most of the time it’s just that simple — someone messed up their configuration. This might be because they were never altered from their default settings, or the new settings were applied in an incomplete patchwork way rather than with a definitive plan.
This category also includes something missed by beginner developers: including error messages in production code which reveal details about the structure of the underlying system. The users don’t need to see those messages, and you’d be surprised what experienced hackers can do with seemingly innocuous information.
Injection
If there’s one vulnerability people have heard of by this point it’s SQL injection — taking freeform user input and processing/storing it without checking it first and without wrapping it as an explicit string instead of a command.
Every database system has convenient ways of solving this issue, so there’s no reason to run into a “Bobby Tables” situation.
Broken Authentication
User registration and login are very sensitive times during which credentials are transmitted and session/cookies are sent back. If this process, and the related process of managing that session, aren’t locked down tight then it can be very easy for those credentials to be stolen or for an active session to be hijacked in the background.
Settings for this can come down to the details of whichever web server is being used. The best place to start here, though, is to get used to using HTTPS for as much as possible.
Sensitive Data Exposure
Only show the exact data to the user that you intend to. Your models might have SSN’s, addresses, phone numbers, or other PII (personally identifiable information) and you need to make sure to filter those out unless the user is meant to have access to it.
Broken Access Control
In a similar vein to the above, it’s important to distinguish user roles based on which actions are available. Managers might have different access than other staff members, and the accounting team could be something else entirely.
Users especially shouldn’t be able to arbitrarily alter information about other users’ accounts! Tailor output and functionality to the specific user as best you can.
XML External Entities
This one applies to older system which still have heavy reliance on XML. It’s possible to include references to other resources in those files which can contain malicious content.
In general, try to avoid processes which can be easily piggybacked by hostile actors.
Cross-Site Scripting
The other highly buzz-worthy entry on this list is XSS. This is an enormous subject that’s had some cat-and-mouse aspects between white-hat and black-hat hackers trying to figure out the latest style of vulnerability and protection.
The crux of the issue is allowing code, insecure user data, or any other insecure source to make alterations to the current page. Once that’s happened, they have as much control as they’d like. This video is an oldie but goodie. (Tom Scott is a very smart guy and great presenter)
Insecure Deserialization
We often need to store objects as string formats in order to transmit them across the web. JSON is the most popular such standard these days.
When translating those strings back into objects we have to be careful that they don’t subsequently trigger their own internal scripts. Isolating where deserialization happens and enforcing strict type checks are good ways of mitigating this risk.
Components with Known Vulnerabilities
Make sure you know which third-party tools you’re using. They can come with their own security vulnerabilities that you’ll have to account for.
Do your research on them, pay attention to what any related communities might have to say about it. In the end it might turn out that the component you wanted to use is just too insecure to be worth it, despite the great features it offers.
Insufficient Logging and Monitoring
It’s hard to know that you’re been attacked or breached if you don’t log what’s happening on your systems. It’s best practice to record as much about user and network activity as possible, and to regularly review those logs for abnormalities. If you can set up direct monitoring for some highly sensitive areas that give real-time messages, even better.
This one can feel like a real pain to run everywhere in your code, but it can pay off big if something goes wrong. It’s typically several months before malicious activity is even detected, by which time it’s too late. Shorten that time and you’ll be ahead of the pack.
Fin
Whew, we made it…
That’s a lot of information all at once, but we’re still just scratching the surface of web security. It’s as deep a rabbit hole as there is in software, but hopefully this primer gives you a sense of what’s there as you continue to explore. Stay safe out there!
