Live data from Hacker News

Advanced web security topics

blog.georgovassilis.com

11–15 of 15 posts

Re: Advanced web security topics

#11
post #9

> 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 u…

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.

Re: Advanced web security topics

#12
post #4

>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 (ra…

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.

Re: Advanced web security topics

#14
post #4

>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 (ra…

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.

> user input needs to be validated at every level

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!

Re: Advanced web security topics

#15
post #4

>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 (ra…

> use CSP's disown-opener to fix this globally

Except no browser supports it yet (see table at https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)

Post reply on HN