[WEB SECURITY] Web security improvement ideas

Ivan Ristic ivan.ristic at gmail.com
Thu May 26 05:22:20 EDT 2005

On 5/25/05, Byrne Ghavalas <security at nscs.uk.com> wrote:
> Hash: SHA1
> Some interesting points Ivan.
> Playing Devil's Advocate, I have a few comments regarding some of your
> points [I am not attacking your ideas - simply trying to engage in some
> healthy debate ;-) ]

Please, go ahead! :)

> I like the idea of breaking backward compatibility - supporting legacy
> protocols and components lends itself to insecurity.  In what way do you
> envisage changing the browsing experience?

Just enough to make it very clear whether a user is in a secure
application or not. I was thinking about a thick red line around the
browser window. A small icon in the bottom-right corner (what we have
now with SSL) is not good enough in my opinion.

> | * Add one new HTTP header, to contain an URI to a descriptor that contains
> |   more information about a Secure Web Application. The descriptor should
> |   allow application authors to exercise great control over what happens in
> |   a Secure Web Application. E.g. they may decide not to use client-side
> |   code at all. Or not accept Flash objects (the browser should then refuse
> |   to run them even if they appear in HTML).
> Could you explain this further?  Does the descriptor impact on the
> client (browser) or the server or both?  How would the descriptor be
> protected?  If it can be manipulated by MITM or other attacks, how would
> this impact the application?  Could the URI be manipulated to allow
> additional privileges or change the level of control?

The descriptor would only impact the client. Since SSL is mandatory it
should not be possible to perform MITM attacks (but it is also
possible to digitally sign the descriptor).

> | * Browsers should remember the SSL certificate of a server upon the first
> |   visit of a web site. If the certificate changes browsers must refuse
> |   to communicate with the site.
> OK - How does the browser know to trust the web site and cache the SSL
> cert, in the first place?  Also, if the cert is changed (perhaps it has
> expired) then how would the admins go about updating the cert without
> impacting the users? What if the host name is changed (say due to a
> company takeover or re-branding exercise) then would the browser
> recognise the old site or would it simply treat it as a new site /
> application?

The key to success here is to use an authentication method (such as
Digest auth) that allows for server authentication. E.g. if your bank
sends you a password and you attempt to use it on a site somewhere,
you will know you are at the right place because the server knows your
password already. The same logic can be applied for name or
certificate changes: as long as the server still knows your password
the transition can be made safely. In effect, if you have a password
it doesn't really matter what is written in the server certificate.
But if you don't have a password you would still have to look and make
a judgement whether to trust the site or not.

> | * No information must go out of a web application (e.g. external links
> must
> |   not be followed, no requests from the client-side code)). No
> | information must go into
> |   a web application. We may need to have designated input and output
> | areas. We may
> |   allow the application to screen requests before allowing them.
> Hmmm.. This appears to be a tricky problem.  How do we handle
> interactive websites?  If a user is required to register for example,
> what happens in this instance?

Sorry, I did not make that clear enough. Information must not follow
out of a secure web application, but the flow from a user to a server
that is part of a secure web application is still allowed. The idea is
to prevent attackers from getting the data out through XSS (not 100%
possible, we would in fact be shutting down one of the channels only).

> How does one prevent external links from being followed?

That's something for the browser to check. If it encounters a link
that falls outside the application it must simply refuse to follow it.
External links are a dangerous weak point.

> | * Separate cookies from session tokens, produce a new state maintenance
> |   RFC that is non-ambiguous. Session tokens are not to be accessed by
> |   client-side code. They mustn't be visible to the end user either.
> Make session
> |   tokens worthless by separating authentication from session
> management (e.g.
> |   require authentication to take place for every request).
> Interesting - but is continual authentication usable?  Users already
> complain about signing on - if they were to authenticate every request,
> it may make the application unwieldy.  I'd go so far as to say that even
> if users used the application, they would stick with simple and easy to
> use passwords - reducing the overall security of the application.

Users would need to authenticate only once, just as they do now. The
browser will take care of it from that point on.

> | This idea is not related to the Secure Web Application concept:
> |
> | * Enforce strict web application interfaces on the web server level. Every
> |   application should be accompanied by a descriptor of some kind, to
> |   specify exactly what is allowed and what not. For example, it should
> |   allow the application to specify which requests it is willing to
> |   accepept, parameter names, and types. Naturally, this descriptor should
> |   not be made publicly available.
> Makes sense.  Although, I would argue that security by obscurity isn't
> ideal.

Now, you wouldn't give a map for a secret facility to a potential
intruder, would you? :)

> Even if this descriptor were publicly known, it should make no
> difference - the app should still be designed to respond as expected and
> only accept legitimate data.

It depends. For example, the descriptor would possibly cover the whole
of the application where the attacker would typically have access to
one part only.

> Even if an attacker knows what parameters
> the app accepts, it should not be possible to defeat the app due to the
> fact that data is properly audited.  For example, if an application only
> accepts an integer value, and I know that, there should be nothing I can
> ~ do to make the app accept a string value!
> I like your ideas - I'm just not sure how easy they would be to
> implement.  Creating new web applications with no backward compatibility
> is tricky - at what point do we kill the legacy stuff?  The OS, the web
> server?  What about the development languages themselves?
> The other issue is of course commercial - would companies support the
> change and pay for the new development - how much would they have to
> spend and how much extra security would they get for their money?

The companies are already losing a lot of money due to security
problems and phishing attacks. So it's in their interest to upgrade.
The changes to existing applications should be minimal. The only major
change is to the way authentication is performed. Everything else
happens in the layers that are external to the application.

Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

The Web Security Mailing List

The Web Security Mailing List Archives

More information about the websecurity mailing list