Fwd: [WEB SECURITY] Web security improvement ideas

Ivan Ristic ivan.ristic at gmail.com
Thu May 26 05:18:32 EDT 2005

---------- Forwarded message ----------
From: Byrne Ghavalas <security at nscs.uk.com>
Date: May 25, 2005 6:38 PM
Subject: Re: [WEB SECURITY] Web security improvement ideas
To: Ivan Ristic <ivan.ristic at gmail.com>

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 ;-) ]

I haven't posted this to web sec - feel free to post it up there if you

Ivan Ristic wrote:
| Several months ago I promised to send my ideas for web application
| security improvement to this list. Please note that I am not claiming


| So here they are:
| * Introduce a new concept called "Secure Web Application". The main
purpose of
|   this is to make it possible to break backward compatibility.
|   The idea is to market Secure Web Applications as really
|   secure and everything else as potentially insecure. Visually, they
|   appear very different than the normal browsing experience.
|   The remaining ideas apply to Secure Web Applications only.

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?

| * 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?

| * 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 /

You mention an SSL change / upgrade mechanism below... Wasn't that the
idea behind PKI and CRLs?

| * Only valid certificates should be acceptable for Secure Web
| * Allow some mechanism for SSL certificates to be changed/upgraded.
|   one already exist?) For example, the server could keep old
certificates around
|   to use them for the transition.

Is it possible to have multiple certs for one application?  Assuming the
cert is changed or upgraded, the browser would need to know what to do?
~ How do we prevent this mechanism from being attacked?

<Several points snipped>

| * No information must go out of a web application (e.g. external links
|   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?  I agree that screening the data makes
sense - only allowing valid data in to the application.  In theory, a
module should strip data back to plain text - then only allow valid
characters... At least for normal text data anyway.

How does one prevent external links from being followed?

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

I have heard of some banking institutions issuing smart card readers.
Access to the site requires the cert on the smart card as well as a
user's password and pin.  Any 'critical' transactions, such as paying
money out of the account requires the user to key in a pin or some other
password - this coupled with the cert on the smart card helps increase

|   [Note: With some effort it is already possible to tie
|   in session tokens to SSL session ids for added protection. But this is
|   not portable, and I don't think SSL should be involved with session
|   management anyway.]
| 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.  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.  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?


Byrne G


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