Link to home
Start Free TrialLog in
Avatar of MarianoSB
MarianoSB

asked on

Angular.JS OWASP #4 Insecure direct object references

Hi Experts,

I would like to know about strategies against OWASP #4 Insecure direct object references, when building Angular.JS SPA.
I've seen videos (http://www.youtube.com/watch?v=6uloYE87pkk&t=33m00s) saying that basic $resource definition is insecure, but it doesn't mention how to avoid it.
suggestions?
I would prefer to read about professional experiences rather than to internet resources , Thanks!!
Regards,

Mariano
(please excuse my english).
Avatar of MarianoSB
MarianoSB

ASKER

Thank you Ray.
ASKER CERTIFIED SOLUTION
Avatar of Ray Paseur
Ray Paseur
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Avatar of btan
btan

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Excellent explanation from Ray!

I use JSON web Tokens via Satellizer and Express.js via node.js so that my access to the database remains as simple as possible - pure REST.
Hi everybody, first of all, please excuse my delay. All comment's are excelent. I would like to know if you have implemented that kind of solutions and if you can share your experiences. By the way, i have seen that some of the approaches, use sessions to store ids, what if the system is pure REST?
Best regards,

Mariano
Likely the session id or token will need to be embedded with the rest call GET
Purely RESTful systems that require authentication usually use an API key, and send the key on every request.  Example in this article.  There is little risk if the transmission is over HTTPS.
https://www.experts-exchange.com/articles/12239/Introduction-to-Application-Programming-Interfaces.html

OAuth may be a reasonable alternative to sending the API key on every request.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hi experts, thank you to all for your excellent comments. I'm currently using JWT to authenticate my api calls against RESTFull API (later i'll open a new question about centralized key management because im using JWT with node and PHP), but I still (and please excuse my lack of understanding if you clarify it allready) can't get a proved method to hide "123"  in some http://mydomain/user/123/inscriptions call (please asume that by the moment i cant change pk system)
I was thinking about to use som bi-directional crypt on the routes.. (something like JWT but with another key ) But before inventing the wheel i prefer to use some proved concepts.
Something that now i see more clear , is the fact that i must change traditional PK to random.
I can't be more grateful to all of you for posting.
Best regards,
... can't get a proved method to hide "123"  in some http://mydomain/user/123/inscriptions call (please assume that by the moment i cant change pk system
Well, then you have OWASP #4 and you are stuck with it.  The point of OWASP #4 is to get away from predictable keys in URLs.  If you can't change this, you just have to accept the vulnerability it creates, and move on.  If you can change the keys to something like pseudo-random keys such as well-salted md5() strings you may want to do so, because that is how we mitigate the vulnerability.

Best of luck with the project, ~Ray
I must admit I don't understand the problem. A JWT should contain all the information you need. It is ONLY decoded on the server (here in Node). Any URL concerning a particular user, where the back-end database needs an user identifier, is send first to node, which decodes the JWT and adds the identifier from the payload onto the URL which is sent FROM NODE to the backend. If the back-end requires authentication it is provided by Node NOT the Angular App. Only Node knows the secret for encoding/decoding JWTs. Node should NOT keep a list of who is logged in with their passwords. The back-end should provide an authentication service which produces the payload for the JWT (note NOT the JWT).
Just to be clear.

The back-end is http://localhost/user/123/inscriptions

the front end sends to node http://mydomain.com/user/inscriptions + JWT

Node decodes the JWT and creates a back-end URL by inserting from the payload the ID.
Thank you both for clarifying, BigRat now i finally understand your approach, thank you very much. I will close this question now .
Best regards,

Mariano
Great comments from 3 remarcable experts