UserSessionToken and modifying / hacking userid in localstorage

[Johny]

Hello,

I've been trying to get some understanding of an issues i'm having, and hoping that someone here can explain me how this really works.

For my app I created a login service that returns a sessiontoken that I will store as a LSV. I also store the username as a LSV.

Now i have secured by collection in the database and it all works fine that if i don't have a valid sessiontoken, it won't let me retrieve any information.

As part of my query I narrow down the result by using a "where" item with the following javascript: return '{"$and":[{"UserName":"' + localStorage.getItem('userid')+'"},{"Status":"Active"},{"Type":"Word"}]}'; This part works fine for the initally stored userid.

The problem I have is that I can change the userid under google chrome for example and rerun the app. In this case i have a valid usersessiontoken, but the result I get is not for the userid I logged in for with username and pw, but for a userid i "hacked". Now obviously it's maybe a bit unlikely that I could guess all userid's, but still it makes it very easy to bypass any security aspect.

I'm probably making some very basic mistake and hope that someone can point this out to me. Should i use the ACL somehow or is there a method where the usersessiontoken is binded to the userid and that this can be checked easily.

Thanks

[Bruce Stuart]

Johnny,

So - quick question then - your app is 'borrowing' the credentials from the browser during 'login' - and does not have credentials of its own ? thus the challenge ?

Bruce

[Evgene Karachevtsev]

Hello Johny,

Also please detail, do you have this issue only in a browser or in a device with installed app too?

[Johny]

Hello Bruce,

I'm not sure if I understand your question But I think yes, I guess it's borrowing it, although it does return a usersessiontoken (which i'm storing in the browser)

But let's say that I've been building something like http://devcenter.appery.io/tutorials/... with the difference that I'm using a where filter to narrow down the results from the DB, because I don't necessarily want to limit the search to what the user created. In order to know what information to pull, i'm using the stored userid from the user to pull information, but this userid can be changed in the LocalStorage. This means that the user potentially will pull (and also update) information that he shouldn't.

[Johny]

Hello Evgene,

I didn't deploy this to a device, but the idea is that in the end I'm using Appery for both browser and app. Even if it would be on an app i guess it would be possible to modify or fake the localstorag value.

[Johny]

Anyone who can tell me what I need to do to make my application more browser secure?

[Evgene Karachevtsev]

Johny,

We are working on it and will get back to you with the update.

[Johny]

Hello Evgene,

Maybe to help a bit here, it's almost the same as https://getsatisfaction.com/apperyio/... . You were actually involved in that as well.

And I kind of have the same issue that I don't want to run a script on every query (because it's not even every page because the LVS can be changed at any time) to see if someone changed the LSV.

I tried to write down the process again and hope I don't confuse you guys even more:

I have a standard login function, based on username and password, which as a result will store the username, userid, sessiontoken (and if needed password) as a LSV.

When i run a query on a collection, I will use a secure collection based on a sessiontoken. now this sessiontoken as I understand it will ONLY tell me if the user can query the collection because it has an active sesssion, it doesn't tell me if the user is who he is, especially if I base the result of my query on the userid that is stored in the LSV. E.g a user can "guess" this userid and with any valid user session it can query any guessed userid data by changing the userid LSV.

Now what I could do is to add some sort of check that would check every time I query if the usersession (that I cannot change I believe) belongs to the userid in the LSV and if not let the user log in again.

There must be something simple I can do

[Evgene Karachevtsev]

Hello Johny,

We are very sorry for the radio silence here. It is very easy to hack, if you know were to find:
1) local storage variable name
2) login service name
3) time when to make switch

a) Triple all efforts for those who doesn't know all that
b) All code are obfuscated for end app
c) Unless your going to publish your app as a web app, nobody could have ability to launch console for your app

Nobody could guess userid, but you are talking about username, which is also highly unlikely to guess.