I'm working on a user authentication library in PHP. Right now I have both stateful and stateless CSRF protection, everything's secure. My problem is that the API is for remote applications (mobile app, game, etc) and has a public facing script to let a client app perform requests to authorize/log in a user. I would like to include the functionality for creating and removing a user in this API so that the client can do everything itself, but can't figure out a way to make it so that the creation script couldn't just be hit by anybody to flood the database with fake users. When creating a user with the API, I don't require any credentials other than username or password in the request, which means that anyone could hit that script. Does anyone know of a secure solution to this to prevent an attacker from using the API to create/remove users themself?
you could increase obscurity by requiring a secret key. Distribute the key in the client code. However, anyone accessing the client code can see the key and use it. But random people scanning your service wouldn't have the client code, nor the key.
Related
If an app is interacting with server api over https using post method ( JSON objects ), then there is a danger of api endpoint getting exposed and anyone accessing the api.
Is there a way to make sure that api is called only from the designated app.
I did some research on the web and came to know of:
a. manual credential checking using POST method
b. using json web tokens ( jwt)
However my question is: both of these methods a) & b) would require some kind of username/passwd passing from client app to server ( everytime in a. and only once in b.). Now this username/passwd would need to be hardcoded in apk and it can be easily obtained by anyone by decompiling it. So then how are these methods secure?
I think you're misunderstanding how json web tokens or bearer tokens work. Why would a username and password ever need to be hardcoded? You'd supply the user with an interface that accepts a username and password.
In option a, you'd store these locally after the user supplied their credentials and clear it when they exit the application or log out. This would not be recommended as that's what tokens can be used for. Many frameworks already offer support for JWT out of the box.
If using a token, the user still supplies their username and password to authenticate, the server will return a valid authorization token. From that point forward the auth token is passed with each request.
I would somehow use TLS security ... with digital certificates ... to cryptographically secure the network access to the portal. The app would contain the necessary public certificate, possibly obfuscated, which the server could check to make sure that the access is legitimate. Now, no one can intercept the communications, and they can't spoof it without somehow first extracting the certificate information from the app, which is probably unlikely. Knowing that the supplicant does possess a copy of the necessary public key should be sufficient authentication.
Although we don't usually employ it when we use TLS to get to your friendly neighborhood https web-site, modules like mod_ssl do provide a complete TLS implementation including the ability to require and to verify a client-side security certificate, without possession of which the connection attempt will be refused. This might be an ideal situation for that.
I'm currently working on a mobile application with an Objective C developer. Because of the nature of mobile devices and how they work, all data is retrieved through an API I have created.
For example, if the user is trying to find something specific to do with the application on a page (a search maybe), the application would make a request:
http://mydomain.com/api/search?param1=hello¶m2=world
If these calls are made from the mobile device through the application I know they are legitimate requests (what I class as legit, anyway). If they're coming from somewhere else I really need to stop that. For example, another developer could copy the exact same application and use the API I have built on my server and there is no way I know of that can stop them doing that.
Is there a way I can secure the API some how to stop the API from being accessed outside the app?
Assuming there are no user accounts for authentication, the only way to secure the app is to hardcode a security token in the mobile app. And even doing so, it won't be 100% secure, because of reverse engineering.
Your API only receive HTTP requests, so the only way to differenciate a legitimate with a non-legitimate request is to send a further information that will be considered as valid on your server side (as OAuth tokens), but if there are no user accounts, you will have to send an identical token shared by all apps (or following a commnon rule).
I think that the best solution here is to hardcode the security token, it will at least force "hackers" to reverse engineer your app and not just sniffing the network.
My iOS app needs to connect to a mysql server. To accomplish this, I'd like to create a webapp that acts as the middleman between the client side apps and the server side database.
My concern is that someone can simply figure out the URL that my app uses and pass their own URL parameters - and since the webapp has no idea whether legitimate data is being sent from my iOS app vs. someone just typing in the properly crafted URL from any web browser, the system will be vulnerable.
Let's say I have a PHP function for marking a user as "verified" (after I send them an email verification code). This is pretty standard stuff, but what's stopping someone from making the same request from a web browser?
Of course, the user that the app uses to make database queries will have limited privileges, so the rest of the database won't be at risk. However, even having users activating their accounts from outside the app would be catastrophic.
The option that I thought of was using https so that even if the user figures out the URL, they won't know the password and wouldn't be able to sniff it since it's encrypted from start to finish. Unfortunately, https can be expensive for a poor college student, so I'd like an alternative if one exists.
As stated before, there is no 100 % security possible. But there are several solutions that put together give great security.
Https
As you point out, this is an important part , as it prevents sniffing.
Sessions
Use sessions and don't allow any request without a valid session ( except the first, that must authenticate the app ).
Fingerprint
Check the user agent and set extra http headers, to get a fingerprint unique to your app. ( Still someone could sniff, but he needed to use curl or similar. )
Obfuscate requests
Build your query string and apply a hash function. The server needs to implement the reverse function. ?43adbf764Fz instead of ?a=1&b=2
Encrypt
This goes a step further. Use a shared secret to calculate a hash. On the server repeat the same. This is already strong security. In order to break, one needs to reverse engineer your app.
Use unique shared secret
You say it is a app for iOS. Upon installation a unique token is generated by iOS. Have your app register this token with your server. Like this you have a strong shared secret unique to each installation, and there would be no way to hack your web app.
i am writing an iphone app that would need to communicate with our servers. on the server side, im am writing an api in php that the app would talk to. What is the best way to authenticate the apps and basically restrict access to the apps and shut everyone else out?
I need a way of recognizing that an incoming request to the api is a legitimate request from our api.
What other security concerns should i keep in mind and calculate for?
any design suggestions?
i am currently looking into what oauth can do for me here!
I think you don't need oauth because it will only help you when you need authentication involving three parties. Example: your application authenticating a Fecebook user (three parties here: you, Facebook user and Facebook).
I would make sure you use this:
HTTPS (never send password or sensitive data over plain HTTP)
A login.php script that will authenticate your user, and upon valid authentication will generate an access_token for your mobile user.
Each restricted service you provide with PHP will ask for a valid access_token as a parameter to execute.
Make sure your access_token expires after certain time or conditions you might impose.
Look at the big companies? Google uses an API key for all their public APIs so they can track behavior and block if they expect abuse.
Since your API is probably not public you might need more security but then you'd probably need to encrypt all communication :<
I'm planing to create a few simple REST web services to be used by some other applications (everything internal, not facing Internet). For certain reasons the applications should work with SSO (Windows, NTLM or other). The issue I have is how to do the authentication in the web service.
The application calling the web service has no knowledge of the users password so I'm kind of lost on how to authenticate against REST without having the user to login? eg. avoid Basic Authentication
I would like to avoid login due to simplicity for the user and not having to handle passwords in my applications. What are my options? Am I missing something obvious?
Would this be a solution:
create token, pass it to service and store it in database. web service checks if token exists in database. (expiration handling?)
The most common solution to this problem is, as you mentioned, a simple key or token based authentication. This is how a lot of google services (e.g maps) work. You simply generate a key on your service provider for each consumer, store it in your database, and validate that all calls pass a valid key.
More sophisticated options would be HMAC or OAuth authentication. Given your situation, i.e. providing services only within your intranet, I'd say keep it simple and go with a single key authentication.
In the above scenario I don't see the need for handling expiration. Nonetheless, if you'd like to implement it, then you could
on each client request, generate a timestamp based token on the server
in your reply to the request, also include this token
client should use both the static API key and the dynamic token in subsequent requests
server should check the token's lifetime and accept / refuse the request as necessary.