保护javascript前端/ REST后端架构网站的最佳方法？

Question

I would like to build the following project:

• public REST API back end which can be accessed by any authenticated client
• front end with static files in HTML/CSS/Javascript with Backbone.js jQuery calls to the REST back end

In fact, there are three parties in my architecture : the front end, which is a client of the back end, the back end and the user which wants to authenticate on the front end login page.

What is the best way to secure the three parties involved in this architecture ?

In fact, I believe it is just impossible to do a secure app on the front end if I do everything in javascript, so I intend to delegate the authentication/authorization to a proxy layer on my server front end. What do you think about that ?

I intend to use OAuth to secure my REST back end, but I am not sure if I have to use the 2 or 3 legged implementation. What is the right approach in this case?

UPDATE : while searching a deep more on SO website, i found this thread which is exactly what i would like to do, except i want to use Java on server side and not DotNet. If i understand well, in fact my web site is like any client of my REST API, except it is the only one which has the right to create new users' accounts. Because, if my REST API is only accessible by OAuth (like Twitter's one), who can perform the user account creation before ? Am i right ?

Answer 1

One major concern with security with this architecture is testing. Automated tools will have trouble testing this system for common vulnerabilities like SQL Injection, Direct Object Reference . A useful tool for testing strange architectures is OWASP's open source Zed Attack Proxy or the proprietary BURP proxy. Testing will be time consuming and requires someone who has a good understanding of web application vulnerabilities. We often refer to these people as Pentesters .

A RESTful form of keeping session state is to use an HMAC to protect the values from modification. However, this is a misuse of cryptography because it opens the door for attack. An attacker can brute force the secret key used in your HMAC and then modify values such as his session id or otherwise gain access to another account on the system. Cryptography should only be used when there is no other option. This vulnerability is prevented entirely by storing session state in a database, which isn't RESTful.