0

I'm writing a RESTful Webservice with the Slim Microframework and use GET for reading data from a mysql database (select query) and also POST/PUT/DELETE for insert/update/delete rows in the database.

My question is now, is this not a big security issue if everybody is able to write or delete data in the database? But how could I prevent this, I thought the ST in REST stands for state transfer (so the webservice is stateless), which is a contradiction to a state like being logged in or not. And if I would pass some login data with the client which is allowed to write in the database, couldn't a bad guy catch the logindata and fake requests with it and for example delete all entries?

So, whats the normal way to go with this, the only Slim Framework examples I had found always show the route examples, but not how to secure it.

Are there also some opportunities in the Slim Framework to implement this what I need? It should be as easy as possible and the request should be responded nearly as quick as without an authentification or similar. There are no sensitive data like passwords, for me it would be enough that not everybody with a cURL commandline tool can delete all rows or things like that.

Would be great if anybody could explain me what to do and/or give some examples. I also need to know, what I maybe will need to change at the clients which are allowed to send the requests.

Lots of thanks.

Danny Archer
  • 215
  • 4
  • 12

4 Answers4

1

Each request has to be authenticated and authorised.

People often get tied up with the word 'stateless'. This really just means that from one request to the next, the RESTful service has no prior knowledge of the users state.

BUT, the service is obviously allowed to be aware of the authenticated user that has just made a request, else how would it decide if it should allow access?

Therefore, you can 'store' the authenticated user in some variable during each request. Then it's up to you how you use this information to authorize the request.

I like to keep it simple and have all my users as a resource in my URI chain. They make requests like users/{username}/someresource.

I authenticate using http basic authentication (over SSL) and authorise based on the URI. If the request failed authentication, its a 401 Unauthorized Request. If the URI {username} and authenticated {username} do not match, the request is a 403 forbidden. If it is authenticated and authorized, the request is allowed (http code dependant on http verb)

Now that's the web service covered, now on to the web service client. This of course HAS to store state, otherwise your user would have to log in every time they make a request.

You simply store the users session in the application (as per normal session management) with the addition that you store the username and password (encrypted of course) in the session. Now every time a request is made, your web service client needs to retrieve the username and password, and send it with the request to your web service.

GWed
  • 15,167
  • 5
  • 62
  • 99
0

It will be stateless, in the sense that there won't be a session or a cookie, really. You'd normally issue out a key that would be required for INSERT/UPDATE/DELETE.

It is then up to you to pass the key with each request and to determine when a key should expire.

Rawkode
  • 21,990
  • 5
  • 38
  • 45
  • I figured out, that this is called using an apikey. But I could not find an out of the box solution in the Slim framework. Instead I found the git repo of the framework author which has some Slim Extras, which are called for example HTTPbasicAuth. Found here: https://github.com/codeguy/Slim-Extras/tree/master/Middleware Now my question is, if I could use this instead a key, or is this not the right for insert/updates in a database. Could a bad guy not still sniff the auth data (or also the key) and fake requests? Thanks. – Danny Archer Feb 27 '13 at 16:02
  • http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ – Rawkode Feb 27 '13 at 16:07
  • Thanks for this link, but it's not about using Slim framework for that. What about the HTTPbasicAuth I asked above? I'm looking actually for something in Slim, but not sure if this what i've found is useful. Thx again – Danny Archer Feb 27 '13 at 20:21
0

It would be as safe as normal http authenticated sessions. These use a cookie etc to authenticate the connected user to the stored session state.

A stateless service would be no different - the token is passed to the service just as a token is stored in a cookie for normal http. If you are worried about sniffing (IE man in the middle attacks) you would secure the link via SSL.

The authentication token generated by the service would be encrypted and would include a salt which is also verified on the server for each request. You could also limit the session time to suit your paranoia, and also check changes in source IP, user agent etc and expire the user's token if these change.

Nicholas
  • 1
0

I recently ran into similar problem. As recommended by people here, I have decided to go with OAuth Authentication.

I am using HybridAuth A php wrapper for OAuth and out of the box sign in solution for Facebook, Twitter, Google, LinkedIn, etc.

Abhishek Deb
  • 883
  • 1
  • 10
  • 24