It's a nice mix of issues. Web security (client/server-side) is a big field, and keep changing. We need a lot of awareness.
If you like this kind of web security focused articles, our security researchers publish (almost weekly) very basic to advanced web security topics in our blog : https://www.netsparker.com/blog/web-security/ Some of them are very specific like;
While I love reading these kinds of articles, I suspect they’re not the most important thing for most developers trying to build secure websites.
My rationale is that a list of attacks and issues like this requires you to reason backwards from attacks to what a safe approach would be. This is incredibly hard work that most people are not ready to do.
Instead, what you need is for someone to present a set of up to date best practices that you can implement. Here’s one stab at one for the specific topic of file uploads: https://twitter.com/olemoudi/status/1023976897661870083 (not vouching for this particular list per se—I don’t know if it’s missing things, but it seems like it’s on the right track).
Agreed! I think the most important security topics have been well covered elsewhere like code injection, session fixation, CSRF. I wanted to talk about unusual attacks which, however, are relevant to many web applications and most developers (count me in!) were not aware of at the time.
>Stealing web page content by tricking the browser to load the private page as CSS
This exploit is not practical in Firefox. Attempting to read cssRules on an external stylesheet will throw a "SecurityError: The operation is insecure".
Chrome mitigates this via Cross-Origin Read Blocking.
> Phishing with target=_blank links
For defense in depth, you'll probably want to use CSP's disown-opener to fix this globally (rather than trying to make sure all <a> elements are covered) IMO.
I'm glad to learn that browsers tighten security as a response to such exploits. My, personal, takeaway is that user input needs to be validated at every level; if I cannot implement proper validations (e.g. analysis of user-contributed CSS), I'll have to prevent that input altogether.
Possibly the best advice a new web developer can get. Once you realize what kinds of things can happen with unvalidated user input, it really changes your outlook!
> The exploited weakness here was that the website could be tricked into serving a user-contributed image with an HTML MIME type by appending the right suffix to the URL file name.
This vulnerability irritates me. Does the server not even know what resources it owns? Is this practice something that is due to dynamically typed langs/practices?
It feels like the problems that plagued SQL inection before we decided to use parameterized queries
This is a category of problems that can arise when "handover" between different application layers hasn't been tightened. Example: a web application is responsible for generating content, but the web server is responsible for delivering it over the network. The web application does, of course, know what resources it owns, but the web server might set/override the MIME type based on other criteria than the web application. That class of problems is more common as it seems, ie. in the "advanced web security topics" post I talk about how different interpretations of HTTP by proxies and servers lead to HTTP injection vulnerabilities.
If you like this kind of web security focused articles, our security researchers publish (almost weekly) very basic to advanced web security topics in our blog : https://www.netsparker.com/blog/web-security/ Some of them are very specific like;
PHP Type Juggling Vulnerabilities: https://www.netsparker.com/blog/web-security/php-type-juggli...
and some of them are 101 kind of coverage such as HTTP Response Splitting: https://www.netsparker.com/blog/web-security/crlf-http-heade...