Case Study

Web Application Assessment

Industry: Local Government

Location: UK

Scene

Local and central government are using the power of electronic channels to provide services due to the benefits such as lower costs, speed and integration with IT systems. The subject of the project was a web application built by an outsourced supplier. The web site and backend were built using common web technologies and languages

Challenge

It was required to see if access to the web application was open only to authorised users, when authenticated users should only be able to manipulate their own data within limits applied by application logic. As the backend database contains sensitive data it should be protected from the Internet from authenticated and unauthenticated users. A middleware layer was used as a component of the application to provide a layer of abstraction between the front and backend. Its workings were required to be investigated in order to evaluate if there are any weaknesses at this level.

Engagement

To return the most value to the client the engagement was executed as a web application assessment. As very little documentation was produced by the outsourced supplier their staff were called upon for interview. The interviews were performed as a part of the project in order to assist in providing a comprehensive picture of the application architecture and its workings. The web server, backend components including the middleware and the application itself were all included in the project scope.

It become clear early in the engagement the supplier was new to building web applications. Dynamic parts of the application were investigated using open source manual web interception software and current web application assessment techniques

Results

Several security issues were discovered encompassing technical and organisational areas.

Web clients are required to authenticate to the application using credentials which are supplied to authorised users of the application. Once the web client logs into the application using the credentials it was seen that these are set as cookies in the client browser. The credentials were then passed for each transaction request sent by the client browser.

This is opposed to the current best practice whereby after initial authentication a difficult to brute force session token is set in the client browser and used for subsequent requests. This session management code was written by the outsourced supplier rather than using the APIs supplied with the web server or programming language which are tried and tested.

As the project contained sensitive information which would traverse the Internet HTTPS was used to encrypt information while in transit. In this instance HTTPS was misused. The encrypted session should start before authentication credentials are passed to the server side. It was found that the HTTPS session is started after the authentication details are passed.

All the stages at which input is taken from the user were tested for XSS (Cross Site Scripting) security issues, several instances were found. XSS security issues could be used to log into a valid account in use by a user of the application. A 'phishing' style attack could also be mounted by exploiting such security issues.

The application which was delivered fell short in areas which ultimately had affected security. Part of the reason for this is the outsourced supplier is relatively new to building web applications. Another reason is that it was not given any documented standards to adhere to when designing and building the application.

Interviews were required with the suppliers of the project as little or no formal documentation was available describing the project which was delivered. This suggested weaknesses in internal processes. It was advised to tighten specific areas of policy relating to the production of documentation before project hand over.

Risks to business

Financial loss, image degradation and the leakage of sensitive information could all result from the security issues which were discovered including authentication weaknesses, misuse of encryption and XSS.

Modifying code to secure the project after the security assessment in order for it to adhere to best practice would translate directly into financial issues for the project as go live date was affected.