New Paradigm Needed For Securing Web Applications

Thursday, September 6, 2007

The Browser Security Model
The Web is, by its nature, a difficult system to secure…..Because each request attempts to be stateless, the server itself must maintain all the state governing a user’s actions.  Unlike an application, but like remote login, no single, long-lived session is maintained between the client – aka the user’s browser – and the server…..Authentication is a good example…..Most applications have username and password schemes where each user is assigned a unique username and then selects a password that is known only to that user…..The problem is, whereas with a time-sharing system users had some sort of unique mapping between them and a communications device such as a terminal or long-lived network connection, with the Web that is not the case…..The way in which large Web applications maintain authentication state is to depend on cookies, which are set by servers and stored in the browser, and to depend on the browser to implement what is now called the browser security model, though it ought to be called the cookie security model.  This model is a contract between the servers and the browser, stating that the browser will send cookies only to a server in a domain that set them in the first place.  As in any protocol implemented independently by several parties, different implementations have different bugs.  This means that the security model as implemented by Mozilla in Firefox is likely slightly different from the one implemented by Microsoft in Internet Explorer, and those are different from the one implemented in Opera, and so on.  The security model is actually the union of all the available implementations.  Protecting your system from only the browser with the biggest market share always leads to trouble…..In a Web application the user’s cookies act as an authentication token to use the system…..Suffice it to say that cookies need to be cryptographically signed to make sure that they aren’t tampered with and have to be issued only after a valid password or other piece of information is verified by the servers…..The scope of a cookie refers to how many services it can access.  From the user’s perspective, a company’s whole Web site represents a single application…..There are other risks with having too tightly defined cookies and requiring users to type their passwords more often.  One of the reasons that phishing is so successful is that users have been conditioned to type their passwords in response to a particular page…..Deciding how long cookies should remain valid is also a security issue…..The problems of cookie scope and lifetime have not been solved.  Most sites, however, have their own rules of thumb, which they attempt to keep internally coherent.

Request Forgery
Once users have logged in and their browsers are dutifully sending their cookies to the server on each request, another problem arises.  What if users are able to make modifications to their data on the site they’re using?…..If the URL of the service that is being used to perform the update is easily guessable, then the user is open to request forgery.  In a request-forgery attack, the attacker creates an URL that will cause something to happen to the user’s account when the user clicks on it…..The server needs a way of figuring out that the user actually meant to take an action.  One way is to request the password again on such an action, or the server can make each URL unique in some way, usually by requiring that a signature be generated and put into any URL that takes an action on behalf of the user.

User-Generated Content
…..Almost everything interesting that can be seen on the Web or any advanced UI tricks are performed with bits of JavaScript downloaded from the Web server and operating within the browser…..JavaScript can also grab and manipulate the user’s cookies and other metadata.  Browsers do not follow the same restrictions on executing JavaScript that they do on setting cookies.  A browser will accept JavaScript from any location that a page tells it to.  Unlike cookies, JavaScript does not adhere to a security model based on the domain name of the site.  Once a piece of JavaScript has control of your browser, it can do anything, in any domain it likes, no matter from where the code was served or from where it makes additional requests.  One of the risks with JavaScript is that a company has to trust what it’s serving up to its users.  A company that serves third-party JavaScript is taking a serious risk with its site because if the third-party JavaScript is malignant, or just contains errors, those problems will directly affect everyone who is served that page.  The problem is not just a third party serving JavaScript.  Many sites now allow users to customize their pages by adding JavaScript to them…..The biggest challenge facing Web sites now is making UGC safe….It’s simply not possible to have human editors review all uploads by all users before they are pushed out onto the network.  Virus-scanning software and other blacklist-based solutions go only so far, as the scanning software needs to be constantly updated with new signatures to prevent new attacks from spreading.  You might think that as long as code is not shared among users, there is no way for a virus to spread, but with the advent of the JPEG virus, which inhabits the header of JPEG-encoded pictures, even allowing users to upload photos provides a vector for viruses…..The challenge for any site that wishes to allow users to upload and share data is how to do it safely and how to protect the users from each other…..Most sites now allow some form of UGC, and the smart ones do this by having a very restrictive whitelist of allowable things the user can upload.  These whitelists can take on many forms.  If the UGC is in the form of HTML data – for example, an online review – then users are restricted in which tags they can use in their text.  They are usually allowed bold, underline, italic, and other simple formatting attributes, but they are not allowed to upload full HTML or to use script tags.  In the case of photo sharing, the photo can be programmatically resized when it is uploaded, which destroys any data the user had in the JPEG header.  To prevent people from instigating a denial-of-service attack on a video-sharing site, the uploaded videos are limited in size.  Each type of UGC must be taken on a case-by-case basis.  What works for photos may not work for video and vice versa.

What the Future Holds
…..The fact is, the Web, and the Internet that underlies it, was designed as a collaborative system for people who were, for the most part, going to behave well and not act maliciously.  We are now long past the era where those design principles made sense…..A better model of who can do what and to whom when a user is viewing a Web page is one step in the right direction.  The browser security model, which depends on domain names to decide who receives the user’s metadata, is probably too coarse of a model to make applications any more complicated than they already are…..People are still designing new systems for the Web that actually attempt to get around the limited browser security model, allowing unfettered access to data in one domain from another.  This is clearly moving in the wrong direction.  Depending solely on cookies – in particular, those that have a scope global to the entire domain of a Web site – does not work well for systems with multiple services.  It’s time to find a new way of implementing sessions in the sessionless protocol that is HTTP requests.  Finding a good way of preventing request forgery must be a component of any solution proposed for the session problem.  The RIA (rich Internet application), where more work is done using JavaScript or Flash in the browser, is the next frontier for security issues on the Web.  Issues such as input validation and preventing malicious data from getting into the user’s workspace become more difficult when the source code is downloaded to, and visible in, the browser.  It will be very important for programmers to make sure that any sensitive data is verified by the server before the application acts on it…..

Reference : http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=496

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: