
Advanced web security topics - ggeorgovassilis
https://blog.georgovassilis.com/2016/04/16/advanced-web-security-topics/
======
fmavituna
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/](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...](https://www.netsparker.com/blog/web-security/php-
type-juggling-vulnerabilities/)

and some of them are 101 kind of coverage such as HTTP Response Splitting:
[https://www.netsparker.com/blog/web-security/crlf-http-
heade...](https://www.netsparker.com/blog/web-security/crlf-http-header/)

------
hyperpape
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](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).

~~~
ggeorgovassilis
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.

------
ggeorgovassilis
Author here; I collected uncommon topics affecting web application security,
such has extracting a page's content with CSS injection.

~~~
64738
Looks like a good read, I think I'll enjoy it.

Thanks!

------
lol768
>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.

~~~
ggeorgovassilis
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.

~~~
chris_st
> _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!

------
eswiac
Great list, thanks! I might add a few of these in
[https://github.com/quarantyne/quarantyne](https://github.com/quarantyne/quarantyne).

------
platz
> 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

~~~
ggeorgovassilis
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.

