Web Security in a Rich Client

views:

answers:

+3 Q:

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

+2 A:

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.

Nissan Fan 2010-06-21 19:05:10

md5 is insecure, and i have no idea what attack you are attempting to defend against by hashing data in transit.

Rook 2010-06-21 19:15:31

His whole appraoch is insecure, but the reality is security is about layers and not about building Fort Knox. If he must do what he says he should at least take some steps to limit the potential for compromise. I think you're taking your security textbooks and wikipedia too literally. In the real world he has a requirement and in order to meet it must make tradeoffs. My point is, if he has to do this at least take some steps to add layers of security. I suppose you would recommend he disconnect the app from all public networks, use biometrics and quantum encryption?

Nissan Fan 2010-06-21 19:23:47

md5 is a one way function. https prevents ease-dropping, what attack are you trying to defend against?

Rook 2010-06-21 19:29:35

@Nissan Fan Not at all man, i'm as down to earth as it gets when it comes to security. I write exploit code and thats where the rubber meets the road :)

Rook 2010-06-21 19:30:50

You're thinking attack vectors, while I'm thinking data privacy. If the system is compromised all that they will have are hashes in my approach, you're suggestion relies on a single layer of SSL which wouldn't suffice under any Security Policy I've ever seen. I've done Infosec best practices in the application domain for multinationals for many years. My recommendation is based on his requirements and the idea that layers of security create barriers. You assume an SSL loadbalancer will always be configured correctly.

Nissan Fan 2010-06-21 20:08:25

@Nissan Fan what you are describing is a "defense in depth" approach. However it is also a waste of computing and human resources and i don't think the trade off is appropriate when the alternative is to make sure that https is working properly. Further more insisting on using MD5 on SO will make people question you, espically when a 4 byte change to your code (using sha1) makes you far more secure and the use of sha-256 is even better. The use of a secure crypto privative is trivial to implement, i don't know why anyone would insist on using a broken system.

Rook 2010-06-21 20:38:13

+3 A:

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

sri 2010-06-21 20:18:11

+1 this is the right answer. Thanks for the recap i guess i didn't read the question closely enough.

Rook 2010-06-21 20:32:42

ansaurus

tags:

views:

answers:

Web Security in a Rich Client

related questions