lekropasky:
Good Job is really going on here. I have some questions Boss. As a mobile app developer -Android, i am a noob when it comes to security, and it bother me alot. i have a software that communicate with a rest service, and i dont want some hackers to abuse my Rest Api, lets say i have a php file that handles user login with an address like --http://www.example.com/rest/login.php?user=username&pass=password, someone can just reverse engineer my app, copy the url, paste it inside a browser and maybe grab the raw json that was meant to return to the client. How do i prevent this please? Sends token to server on every http request? How do i verify the token on the backend...i have a lot of questions....THANKS.

a. It really does not matter if you use a GET or POST in your request. Just ensure that you send the traffic over SSL/HTTPS (this is just a minor prevention that can not stop determined Man in the middle attacks).
b. SSL certificate pinning is a good way to reduce the chances of your traffic being sniffed by a third party. It can however be bypassed without much work on most rooted devices.
c. Some apps do check to see if the device is rooted. If the device is rooted they wont run. This is also a precaution and combined with SSL certificate pinning will prevent about 80% of attacks.
d. Another way to mitigate attacks would be to use a shared key thats known to the server. Then encrypt all requests from the client going to the server. This is how most of the payment processors send credit card details. If on a mobile device, ensure the encryption part is done in c/c++ code. For android developers, never encrypt data in Java, always do it in c/c++. There are very good android apk to java decompilers that can convert all your code back to raw or approximate java code.
Will continue Lesson 4 later today.

DanielTheGeek:


That is what the Oauth authorization framework is meant for, you validate apps by sending them to the Oauth server to validate the app_token and app_scope and make sure the user gave permission to that app/person trying to connect.

By password, I guess you mean the api_secret, you should pass them through Oauth first for initial validation. Get Oauth 2.0 https://oauth.net/2/ . Another thing is, your API doesn't look properly designed (if that's the way it is in production) instead of /rest/login.php... Something like /api/v1.0/users/all... makes more sense, but if your API is private you can hard-code the credentials na, this one is public "ashewo" API... let me know if you need me to explain further.

i have actually heard about this, and i remember that i tried to wrap it into my head, but i didnt get it. So, ill be glad if you can show me the basic implementation/example. Thanks.

seunthomas:

a. [/b]It really does not matter if you use a GET or POST in your request. Just ensure that you send the traffic over SSL/HTTPS (this is just a minor prevention that can not stop determined Man in the middle attacks).
[b]b. [/b]SSL certificate pinning is a good way to reduce the chances of your traffic being sniffed by a third party. It can however be bypassed without much work on most rooted devices.
[b]c. Some apps do check to see if the device is rooted. If the device is rooted they wont run. This is also a precaution and combined with SSL certificate pinning will prevent about 80% of attacks.
d. Another way to mitigate attacks would be to use a shared key thats known to the server. Then encrypt all requests from the client going to the server. This is how most of the payment processors send credit card details. If on a mobile device, ensure the encryption part is done in c/c++ code. For android developers, never encrypt data in Java, always do it in c/c++. There are very good android apk to java decompilers that can convert all your code back to raw or approximate java code.
Will continue Lesson 4 later today.

thanks. I kinda like the option d, but does that mean C/C++ codes are free from being reverse engineered?.

DanielTheGeek:

Thanks for pointing that out, but who are we protecting in the first place? The users right?
I think what he'll need will be something similar, since the requests will be coming from the software/app, he can add some sort of randomly generated encryption key that only the server can randomly decode due to a randomly generated unique unlock key used to decipher the key. Please take a little time to see how CodeIgniter's encryption library handles this. Still, this greatly limits the spoofing of your app but not completely, a smart person knows his way around.
So summary is: You generate a random string with a random unlock key and use it to verify the source of the request, decipher on the server side and fetch the required data and POST back in JSON, store the used keys in a database so spoofers can't re-use a key they sniffed.

I don't mind helping him implement it, maybe we should do it together and make it open-source, just maybe.

Exactly!!

But for me, I prefer not to really stress on this... I'll rather do what Snapchat did (They block all accounts not created with the official app like after sometime)....

FincoApps:


Exactly!!

But for me, I prefer not to really stress on this... I'll rather do what Snapchat did (They block all accounts not created with the official app like after sometime)....

Please be original, don't do what I did, thanks

Snapchat:



Please be original, don't do what I did, thanks

ROTFL!
What's snapchat looking for on Nairaland?

Lesson 4 Never take anything for granted
Most of the most humilating hacks that ever happened was because of developer carelessness. The BrowserStack of 2014,Snapchat hack of the same year were all as a result of someone being careless with credentials.

Never keep important passwords,remote login details,cpanel details,ssh details,etc in places where they could be easily accessed.

The most popular security vulnerability in the world is 'carelessness'.

Develop a security consciousness and be very critical about credentials. From time to time change passwords etc.

Some compromises may not be detected until you change your credentials.

DanielTheGeek:

ROTFL! What's snapchat looking for on Nairaland?

Customer bro, Customers!!

Snapchat:



Customer bro, Customers!!

Funny, but on a more serious note, do you know you can serve a jail term for what you're doing? It's called impersonation and you don't want to be a victim. #JustSaying

DanielTheGeek:


Funny, but on a more serious note, do you know you can serve a jail term for what you're doing? It's called impersonation and you don't want to be a victim. #JustSaying

Really?? Lol

Lemme just assume you were joking..


But to address your accusation,
1. It's a fun moniker
2. I didn't register to scam and if I did have not been caught
3. My Snapchat has nothing to do with Snapchat the App ,but I'll admit it did inspire it
4. I've run out of reasons


Finally, Impersonation Is Wrong

Snapchat:



Really?? Lol

Lemme just assume you were joking..


But to address your accusation,
1. It's a fun moniker
2. I didn't register to scam and if I did have not been caught
3. My Snapchat has nothing to do with Snapchat the App ,but I'll admit it did inspire it
4. I've run out of reasons


Finally, Impersonation Is Wrong

No diss man, enjoy yourself.

DanielTheGeek:

No diss man, enjoy yourself.

I'll, you should too


Maybe when you are done I could learn some programming from you

Snapchat:



I'll, you should too


Maybe when you are done I could learn some programming from you

No problem, anytime, make a request here

lekropasky:
i have actually heard about this, and i remember that i tried to wrap it into my head, but i didnt get it. So, ill be glad if you can show me the basic implementation/example. Thanks.

@FincoApps already pointed out that Oauth won't really solve your problem after which I added that tokenization would work, however isn't child's play to implement.

If you still need help on implementing OAuth, let me know here

DanielTheGeek:


@FincoApps already pointed out that Oauth won't really solve your problem after which I added that tokenization would work, however isn't child's play to implement.

If you still need help on implementing OAuth, let me know here

hmmm so you have a blog like this.... you should shout about it more

FincoApps:


hmmm so you have a blog like this.... you should shout about it more

Sometimes some things just speak for themselves, no hype.

@seunthomas well done. I am benefiting from the information.

@seunthomas I have a question.How does one prevent session hijacking?

though am a beginner in programming /html css jscript) for now i think this is the best thread have ever come across in this section nice job

mnairaland:
@seunthomas I have a question.How does one prevent session hijacking?

To be honest with you, there is actually no way to prevent it.

You can actually make it more difficult for sessions to be hijacked.

One way is by allowing one user signup per device. If a user logs in from one device, you automatically sign them out from all other devices. You may need to add some headers in the request to act as a challenge. Thats what snapchat does.

They log you out from all other devices and you have to generate a specific header which is a challenge between the server and client to verify if the requests has been tampered with.

However, like i said, a determined attacker can still bypass this with some effort.

I Will resume the lessons later tomorrow. Have a good weekend.

seunthomas:


To be honest with you, there is actually no way to prevent it.

You can actually make it more difficult for sessions to be hijacked.

One way is by allowing one user signup per device. If a user logs in from one device, you automatically sign them out from all other devices. You may need to add some headers in the request to act as a challenge. Thats what snapchat does.

They log you out from all other devices and you have to generate a specific header which is a challenge between the server and client to verify if the requests has been tampered with.

However, like i said, a determined attacker can still bypass this with some effort.

I used to think people hijack sessions of people who have already logged in. If that indeed is the case then what snap chat does will be completely irrelevant.

I have been searching for a good solution to this but is yet to find one.

mnairaland:


I used to think people hijack sessions of people who have already logged in. If that indeed is the case then what snap chat does will be completely irrelevant.

I have been searching for a good solution to this but is yet to find one.

What snapchat did was to make it more difficult to hijack sessions. But like i stated first in my reply, there is no way to totally prevent it.

seunthomas:

What snapchat did was to make it more difficult to hijack sessions. But like i stated first in my reply, there is no way to totally prevent it.

OK.Thanks a lot.

mnairaland:
@seunthomas I have a question.How does one prevent session hijacking?

You can use a .htaccess file to prevent this kind of attack.
Research on turning of the ID in sessions by using something like:
session.trans_id off (I'm not sure of the exact line of code tho)

DanielTheGeek:


You can use a .htaccess file to prevent this kind of attack.
Research on turning of the ID in sessions by using something like:
session.trans_id off (I'm not sure of the exact line of code tho)

OK. Thanks.I'll look into it.

DanielTheGeek:


You can use a .htaccess file to prevent this kind of attack.
Research on turning of the ID in sessions by using something like:
session.trans_id off (I'm not sure of the exact line of code tho)

I doubt you can, because sessions are passed to the http client. .htaccess wont have any effect.

seunthomas:



To be honest with you, there is actually no way to prevent it.



You can actually make it more difficult for sessions to be hijacked.



One way is by allowing one user signup per device. If a user logs in from one device, you automatically sign them out from all other devices. You may need to add some headers in the request to act as a challenge. Thats what snapchat does.


They log you out from all other devices and you have to generate a specific header which is a challenge between the server and client to verify if the requests has been tampered with.


However, like i said, a determined attacker can still bypass this with some effort.

Nay! I disagree with this method as it sacrifices user experience. What of web-apps that allow users the choice of logging out of other devices manually?

The request verification method is perfect but also turning session id's off makes it more complicated, The way Facebook does it is you get a pop-up requiring you to re-auth to remain logged in the moment they detect any issue with the session.

DanielTheGeek:


Nay! I disagree with this method as it sacrifices user experience. What of web-apps that allow users the choice of logging out of other devices manually?

The request verification method is perfect but also turning session id's off makes it more complicated, The way Facebook does it is you get a pop-up requiring you to re-auth to remain logged in the moment they detect any issue with the session.

Even though SeunThomas's snapchat approach may not be the most pertinent, It appears to me considering this your post that he understands how session works.better than you do.

Http access is stateless. Server have no memory.Once a client connects to a server
the server checks to see if it sends a session id with its request.If a session Id is not found, the server creates a new session id for that client and hands the new session id to the client. The clients saves the session id as as a cookie on the client's computer. Once this is done, the client sends the session id with every request to the server.The server identifies each client app by comparing the cookie they send with the request with the one saved with a client identity on the server computer.

Session , hijacks occurs when an hacker successfully snifs out a client's session id while its being sent with request to the server.

There after,the hacker impersonates the client by sending his own request along with the clients original session id to the server. The server ends up comparing that session id with the one saved with a client identity and it assumes thr request came from the client. By so doing the hacker can carry out adminitative task on the app if the user whose session is hijacked is an admin.

Because the session id is saved as a cookie on the client cimputer,the client can end the session any time it wants by destroying or deleting the cookie.

Having said all these , I now suddenly see why snapchat approach is quite relevant and appropriate because it is unlikely that the hacker will be operating from the same device as the user, so even if the session id from the hscker and the authentic user are thesame it is unlikely that their ip address and any other device related information will be the same.

Pls note that when I said client above meant web
browser and when I said server above I meant't web server as opposed to the client computer and server computer themselves.

Thanks @SeunThomas , I see now that the snap chat approach is the way to go. It may not be 100% reliable , but considering
its format, it would most probably be 90% reliable. The hacker woule have to get, in addition to the session id, other information about the client in other to hijack a session. His greatest huddle would be determining the pool of addional information about the cient thar the web app keeps for completey identifying a client.

DanielTheGeek:


Nay! I disagree with this method as it sacrifices user experience. What of web-apps that allow users the choice of logging out of other devices manually?

The request verification method is perfect but also turning session id's off makes it more complicated, The way Facebook does it is you get a pop-up requiring you to re-auth to remain logged in the moment they detect any issue with the session.

Reading through your post a second time, I think I now understand your point.

You are saying that, rather than ending the session because a foul play is suspected facebook requires the user to re-login.
Hmn, that sounds better truely because it saves user experience like you pointed out.
This means that facebook will flag the session id on which it suspects foul play and will refuse to grant the request of any client request from any device that attempt to use that session id unless the person behind it re-logs in.

Thats actually sounds like a better approach than snap chat's approach to me.

The hacker will not be able to use that session id again unless he uses the device
that is being used by the authentic user.

seunthomas:

I doubt you can, because sessions are passed to the http client. .htaccess wont have any effect.

You can disable passing session id's through the URL by turning it off in a .htaccess file or PHP ini file. This doesn't prevent the hijacking (made a mistake earlier) just makes it less vulnerable.
When use_trans_sid is enabled, PHP will pass the session ID
via the URL. This makes the application more vulnerable to
session hijacking attacks.
Another measure is to disable JavaScript access to cookies so a hacker cannot get access to the session id from a cookie using XSS and force cookies to be sent over HTTPS.

You can even go to the extent of storing the IP with the cookie and when they change, re-auth but some people's ISP's reallocate IP's quickly so you may end up annoying legit users.

From what I have gathered here this is my opinion on how to prevent session hijack.

Ensure login is done per device. This means each time a person logs in you must save sufficient information about the device from which the logged in into your database.

Create a Table probably named UserSession.
Along with other device identity identifying fields that you create in your UserSession Table you must also create a field probably named sessionid.

Insert, along with other device identity identifying information, a randomly generated session id into the UserSession Table.(You might want use the table's primary key instead).

From the server create a cookie using this your application generated session id.

Before you create any page for a logged in user on the server, get the current user's session id from the session id cookie you created and any get all necessary information about the current user's device.

Using the session id gotten from the cookie read/load the corresponding device identity row from database.

Compare the user identity values from database with those of the current user.If they do not match then suspect a fowl play and flag or mark all rows that have that session id in your database.

On suspecting a foul play request the current user to re-log in.

If the re-login succeeds delete that all rows that have that session id from your UserSession table ( since eached saved session id is per user per devuce)

Insert a new device identity identifucatuon row which should include a new generated session id( unless you are using primary key).

Create the user requested page you were about to create before you suspected foul play.

If re-authentication after foul play fails a number if times say,three times, then you can require the user to answer security question or any other higher levek authentication you desire.

Please note that the session id your application creates does not replace the one that the web server creates to identify clients. The web server still carries out its own session and client identification activities wuthout being disturbed.


Do add addition improvement suggestion that you deem necessary.