Web Security in a Rich Client

I'm currently building an web application for a customer that uses a rich client. (Flex)

In this application, a user has a password, as well as a couple of other key attributes that are used throughout the system for identification purposes. (Eg., things like mothers maiden name).

A user logs on with their password initially. Then, throughout the application, whenever a user is about to perform a "destructive" action, they are required to enter one of these other开发者_C百科 identifying pieces of data.

My customer has requested I load these attributes after login, store them in memory, and perform validation against this data on the client, before making a server call that performs the destructive actions.

This strikes me as a potential security risk, as it's possible (albeit difficult) to spoof the web client, and retrieve this data that is sent across the wire. My customer thinks I'm being paranoid and is urging me ahead.

Some key points to consider:

• The application is served over HTTPS
• All client / server communications occur over HTTPS
• This data is sent to the client only AFTER logon has occurred
• During logon, the session is issued with a secure cookie.

So, largely, the application is fairly secure.

However, my gut tells me that while it may be difficult to hack the data, it's still less secure than if we didn't send it at all, and validated on the server.

Am I being paranoid, or is this a genuine security risk?

If this is a valid concern, are there any best practice documents that I can point my client to, in order to substantiate my point?

The check should be done on the server side.

If an unauthorized person gets access to a session id, he can always make a call to server using the session id and download the personal attributes. That is leaking private information to an attacker.

More importantly, the attacker doesn't really care what validations you perform in your flex app. He will just use a network sniffer to see what server calls are being made - and since those server calls don't require personal attributes, he can bypass your security model.

In short, all security validations should be done on the server side. This is a Common Weakness, you can read more about it on this page http://cwe.mitre.org/data/definitions/602.html

If you must do this, send over the pieces of information from the server to the client at the start of the session MD5 hashed. This should be pretty secure. In no situation should you ever send over the actual data itself in the clear unhashed or unencrypted. Also don't persist the data anywhere during the session like disk.

A better approach would be to accept the input and hash it, then send it to the server for validation.

At the end of the day the server should enforce security and not the client. HTTPS is just line-level security. Application Servers should enforce information security rules and not their clients.