In-Depth

Tips for RIA Security

Securing Rich Internet Applications requires an understanding of their vulnerabilities

• By Itzik Spitzen
• 08/19/2011

A Rich Internet Application (RIA) is basically a Web application with a rich, graphical UI. The elements that define the "rich" in an RIA include drag-and-drop functionality, fast mouse-click responses, and instant state change of visual UI components without affecting the rest of the screen. 

The growth of RIAs is exploding, but that brings increased risk with it. Many developers don't realize the numerous ways information exposed in the browser can be compromised.

That's because the information that causes security vulnerabilities is not the information received as input from the user or output to the Web page; rather, it's the various pieces of data that make the application tick. What follows is a guide to understanding these data items and what opportunities they present to a user with malicious intent.

Database Connectivity and Access

The Vulnerability: Code that contains a database connection path or keys for the accessing of records can be adapted by a hacker to send a request to the server that the application never intended. The implications range from access to private information to making unauthorized database changes.

• Never reveal database connectivity strings in the browser.
• Don't execute SQL by sending the SQL statements themselves on the wire to the server.
• Don't reveal the record structure in the browser.
• If security is important, avoid client-based Ajax frameworks altogether.

Built-in Permissions Management

The Vulnerability: Permissions mapping is an important part of any system where privileges are not identical for all users. It can be implemented by whole fields in a control record, or by bit mapping in a field, or by values passed from the server to the browser. The integrity of those permissions can be compromised if the client code can be altered to override the defined authorizations.

The Remedy:

• Don't reveal your permissions structure in the browser.
• Don't allow any functionality in the browser to affect the authority received.

Hidden and Disabled Functionality

The Vulnerability: Being event-driven, RIAs react to on-screen button clicks, HREF clicks and the pressing of keyboard keys. One way to restrict access is by disabling functions like links and screen buttons in the browser, keeping them from being displayed on the Web page. But the transparency of HTML makes it easy for a hacker to identify these methods, and construct and send a request that wasn't meant to be available.

The problem here lies with the server, which handles requests without examination. This can be mitigated with a robust server-based RIA that excludes the sensitive buttons and links entirely from the delivered Web page (as opposed to being just hidden). While this is a far more secure approach, it still can't prevent the arrival of a fabricated request from a hacker who's learned the options available or guessed the prohibited options. Automated tools that make repeated attempts for different values provide an avenue for hackers.

The Remedy:

• Omit any screen input options that shouldn't be used in the browser page, even if they're disabled or hidden.
• When processing user screen input at the server, check every requested action and only handle the event if it's expected at this time and from the current user. Always assume an attacker knows or at least guesses what controls might have appeared in the screen with elevated privileges.

Third-Party Services

The Vulnerability: Calls from the browser to Web or other online services not only reveal your system's dependencies, but are also likely to expose indentifying information. This information may be used for authentication; for example, user and password data or information returned by the authentication in the form of security tokens for keeping the connectivity path active. Armed with this data, a hacker might be able to access these services directly outside the session. Malicious activity can include automated requests that affect the fees charged by the provider, and denial of service attacks that can incapacitate the service. Multiple open services further increase exposure and vulnerability. 

The Remedy:

• Avoid the necessity of accessing information from external services via the browser. Do this on the server and pass to the browser only the information required for display.

Business Logic

The Vulnerability: RIA models can place their business logic in the browser. There are a couple of approaches in doing this:

• The application may be a client-based Ajax framework, in which case the only place for the business logic is in the browser.
• The application may be a server-based Ajax framework in which development is done on the server in Java or other HLL code, then translated into JavaScript; this is downloaded to the client to reduce the degree of server/client discourse and improve performance.

Both cases reveal the application logic and allow it to be modified on the browser.

The Remedy:

• The best way is to keep any business logic from to the browser.
• If you must have some business logic on the client, make sure that there is no way of overriding the application logic in a way that could compromise the application. This requires extra validation logic on the server side.

Input Field Validation

The Vulnerability: On the face of it, first-level field validation is a classic job to be executed in the client, since it requires no interaction with the database. Such validation tasks might include numeric format checking and sanitation to prevent deliberate injection and cross-site scripting. However, these preventative and defensive measures are worthless if a malicious user can override them by interfering with the HTTP request.

The Remedy:

• If you do field validation in the browser, validate it again at the server.

Contradictory Goals

The RIA finds itself with two seemingly contradictory needs:

• Desktop look and feel and responsiveness.
• Adequate application security.

Desktop-like performance is the very essence of an RIA, while security needs are dependent on the application in question. Therefore, the degree of urgency of the measures listed here can be gauged by the nature of the application.

It's vital that enterprises and ISVs that produce data-centric line-of-business information systems understand RIA security pitfalls. Those that place data security at the top of their priority list will build their applications in accordance with these measures.

Implementing these best practices can be done in one of two ways:

• The organization can enforce a clear development policy of best practices, developer awareness and code reviews. This is the most common implementation of rich Web application security today.

• The application can be deployed using a secured-by-design delivery platform. Secured-by-design means the developer cannot introduce the security vulnerabilities described above. He concentrates on the application logic just as with non-Web client / server applications and is free from the vulnerabilities of the browser. This is the server-based computing (SBC) paradigm, which includes:

• Virtualization of an existing traditional client / server application and its deployment to the Web using a proprietary browser plug-in.
• New server-centric application development in which the platform (and not the developer) produces HTML and JavaScript code that handles the visualization layer and user response, and nothing more.

The Right Security for the Right Application

The architecture of one RIA approach can be fine for one kind of application yet unnecessarily risky for another. If we view the offering of RIA frameworks discussed in this article in terms of their inherent security vulnerabilities, client-based frameworks are undoubtedly the least secure.

Client-centric solutions are excellent for games and graphic Internet applications (fashion virtual try-on, real-estate shopping, and so on) that have a relatively low exposure of sensitive data; but they pose serious concerns for sensitive data-based applications. 

For ISVs and enterprises, the implications of security are great, extending from privacy to contingency, and this must dictate the paradigm they chose. Such organizations have a number of different server-centric solutions available that can ensure their security, each having different costs, scalability, development skill requirements and degrees of modernization.

The development and runtime architecture that gives the most business value and the highest degree of security has the following characteristics:

• Server driven, with complete control over user responses, handling only actions expected from the user.
• Total virtualization of the client code. The client will handle input and output in the browser in a completely anonymous fashion. The only information contained in the browser would be the content of fields' input and output. And the developer wouldn't write a single line of HTML.
• Minimalistic validation in the browser, or excluded altogether.
• Fully supported n-tier architecture.
• All external procedure calls to third-party services made from the server.
• A single communication channel between server and client carrying only raw screen input and virtualized output.
• Modern, HTML5-based client output for maximum user reach, including cloud and mobile.