Protected Url QueryString

[Ivan Assis Leal]

Hello,

It`s possible protect Url parameters, for sample:

#/order/18829

to

#/order/<protect parameter>

Thanks

[Eddie Monge]

For what purpose? What do you mean by protected? Like you can't see it?

[Ivan Assis Leal]

Hello Eddie,

I want to prevent the parameters passed by querystring can be handled improperly. Thus these data must undergo some sort of encryption.

[phindmarsh]

Who are you trying to prevent accessing these parameters?

If you are worried about tampering while 'in transit' (i.e. the request is modified between the client and the server), doing any kind of cryptography in Javascript is not going to solve this problem. If someone has the capability of getting in the middle of your requests, they'll certainly have the ability to modify any crypto you do in JS and reverse it. A solution to this is to use HTTPS. SSL certificates are not expensive (sometime free even), if you are building an application with personal data stored somewhere, I'd strongly recommend it.

If you are attempting to stop a user tampering with the argument to get data they shouldn't see, you should really be stopping the server from returning data that the user is not permitted to view. From your example, I assume you may wish to ensure a user can only see orders which belong to them. In this case you should be checking that the user making the request for an order actually owns it on the server, and returning a forbidden/unauthorised response otherwise. If you simply 'protect' the real order id, but still use that to request data from the server, any savvy user will quickly be able to determine that and get data at their leisure. 

If these are not authenticated requests (i.e. you don't know the user upfront), then rather than using the order id, generate a random token (make sure it's actually random, not just a hash of the current timestamp) and use that to identify the order. You still leave yourself open to random guesses of a valid token, but with one of sufficient length, it becomes impractical, especially with API rate limiting and blocking. For example, instead of #/order/18829 you might use #/order/hsHIu39mxszg61bkds0fjz. This should be generated by the server, and only return order data when a matching token is used, rather than the order id.

Either of these problems should be solved on the server, either with HTTPS or proper authentication/authorisation. Trying to mask/obfuscate data in Javascript will slow down a malicious user at best, and typically just waste your time.

If none of those are what you mean, my apologies for rambling :)

Cheers

[phindmarsh]

Totally just noticed this is a pretty old thread. Not entirely sure why it was showing in the recent messages digest... apologies for reviving an old topic.

[Brian Tan]

No worries. What methods of proper authentication/authorisation would you suggest? Generate a token for each user?

--
You received this message because you are subscribed to the Google Groups "AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/groups/opt_out.

[Patrick Hindmarsh]

For the applications I’ve made, I generally start by making sure any data that is requested by the API is able to be requested by that user, and that they only see the bits they are allowed to. This is done (generally) in two ways.

The first is to identify each user for each request. This can be as simple as establishing a token for that user, and when a request is made, look for that token in your database, check it is associated to a user, and that it hasn’t expired. Its a good idea to rotate these tokens so it a ‘bad guy’ gets a hold of one, they can’t use it forever. If a user logs out it should definitely destroy it. Another common method is OAuth, or some other third party identity service.

To work out a token, you could generate a random string when a successful login occurs and store it. As I said earlier, make sure it is actually random. Depending on your server language of choice there’s likely to be a cryptographically secure pseudo random data generator available. For example, in PHP you could use openssl_random_pseudo_bytes(), rand() is not sufficiently unpredictable.

Once you can reliably determine what user is making the request, you should check that what they are asking for is in fact able to be seen by them. I generally have a permissions system which I can ask ‘does this user have access to see this thing’. A simpler example of this might be an API request that returns a user object, and simply checking that the logged in user is the same as the one being requested. There are so many ways of doing this, but the general idea remains the same.

If you have sensitive data, its not sufficient to just not display it in the UI, but still send it to the client. Its trivial to extract data (if you look at the AJAX requests in the browser developer tools for example) you are not supposed to see, so the idea here is not to send it at all. Make your UI react to the data it gets, which will make your application much more robust and less prone to leaking stuff it shouldn’t. One should always assume the browser is a hostile environment. In angular I have a $http interceptor that will deal with the event where 401/403 response is sent from the api and prompt the user to authenticate if necessary. 

For a bit more technical information into this, OWASP (owasp.org) has some excellent resources for avoiding the common security pitfalls. In particular, look for the OWASP Top Ten (https://www.owasp.org/index.php/Top_10_2013-Top_10), which highlights the 10 most common mistakes when designing a web application. For angular in particular, there are quite a few tutorials/modules that should give you a head start (http://ngmodules.org/tags/authentication)

HTH

You received this message because you are subscribed to a topic in the Google Groups "AngularJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/oglBAn2CRwI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to angular+u...@googlegroups.com.