The docs states that you have authenticate using a User that can modify ex. Members. How do you prevent someone from modifying urls and modify/delete content they shouldent?
Example. If I use this in an Intranet, where my members can login and change or delete their memberinfo I would create a (shared) user account and give it access to the members area. Right?
Isnt it too easy to hack the "DELETE /rest/members/{id}" to delete any member?
Security is actually a real pain, especially when it comes to web services, and especially when it comes to the services existing within a website with it's on security mechanism. The best I could come up with was a custom token based security mechanism. With uRest the first thing you have to do, is request an auth token. This auth token is specific to the credentials you pass, and your IP address. This is then appended to every request, along with your username. Every request is then checked against an umbraco user, and your IP to make sure the request is valid. This isn't the best, but it is better than what comes with the default Umbraco web services.
Unfortunatley, I don't think this is going to help with the example you have given, as yes, if someone was to intercept the request, and execute it within the same IP range, they could indeed just change the id parameter. That said, I would say this is going to be true of more or less any restful interface, really the request should be hidden behind your code so that it's not obvious to your users how it's executing their request. In my opinion, if someone is going to the extend of monitoring their HTTP traffic request to reek havoc with your system, I'm sure they are going to find a way regardless.
Any authentication will not solve this. My point is that it's a real danger to use generic webservices to modify data as the logic to deside whether the accessed data "belongs" to you is on the client. Once placed there it's gonna go wrong.
Thats why I really love Umbraco Base as this only is a tool for you to build your own webservices and you can then build your logic serverside.
Say you have some data that belongs to your member profile. You are allowed to work with these data and not others data :-)
Authentication: In base you have your session authentication and within this you have your current member id stored in sessionmemberid.
Url to serverside base method: /base/datadelete/id
Pseudo source:
public static datardelete(int id) {
// the deal is that base is only a framework - I have to make my own methods but it's easy. And therefore I can make my data logic serverside. res = delete from datatable where dataid = id and memberid = sessionmemberid
And what if you wanted to call that /base method outside of an umbraco context? You no longer have state, thus no longer have your session, thus no longer have security. In your example, the methods are only made secure because you've previously logged into Umbraco. That's great if all you are doing is proxying back into your site, but uREST is designed for a different problem, and that is connecting and interacting with an Umbraco site, outside of an Umbraco context.
Think iPhone app managing your website, or some other app on a completely different server pushing data directly into your site. In these scenarious there is no session state, and never could be, because they are seperated and it's not a logged in user pysically performing those interactions.
Anywho, I think from your example, yes, /base would probably be the best way, but if you want to open up your site to some other third party app, uREST should offer as good a security mechanism as you can get under the circumstances (take a look at the default umbraco web services, they pass a username and password in clear text with each request).
If a third person where to sniff / hack the requests any of the above would be compromised.
My example could be modified to use the token approach. The point is that because I'm not using a general serverside features, I'm able to put in some logic to ensure that any authenticated user only gets to delete his own data. To compare - if I install the general lib, once authenticated, I can delete any node.
I don't disagree, and that is always going to be the case with any "generic" web service layer. The example you've outlined is very specific, and yes, could be made more secure than uREST by using a specialized /base method. But if you were to write /base methods to handle all the scenarios uREST can handle, you are going to hit the exact same security problems.
I think at the end of the day, it's about using the right tool for the job, based upon your needs. If you need the upmost security, and don't mind reinventing the wheel creating your own /base methods every time, then go with /base. If you'd prefer to just plugin a set of pre-built web services that can do EVERYTHING but at the risk of being a little less secure, then choose uREST. To have the choice surely can't be a bad thing.
I agree - both has it's strong points and uRest is cool because it can do EVERYTHING :-) As long as the risks are known to everyone.
Maybe being able to configure the operations allowed in the areas might be very handy. To be able to allow only GET for member and media operations and say no access for rest.
That's not a bad idea to allow the configuration of which methods enable/disable, I'll look to add it in the next version. I knew this convo was leading somewhere =)
And in version 3 you might even be able to configure data ownership checks. That would solve almost everything. Like "has to be logged in", and "profile property compare with data property".
If I can just interject here: nobody can sniff your requests if they go over HTTPS unless there's a proxy server in the middle that does some request spoofing, which you should be able to detect by validating certificates.
Jesper: If someone listens in during login (without using HTTPS), they can just as easily see your credentials and it is just as easy to take over their session.
HTTPS and certificate checking is the silver bullet here. I don't know how easy it is to validate certificates though.
I'm with you totally. My concerns was never about sniffing/hacking nor authentication. My focus (mayby I explained myself very badly) is on what an authenticated user can do with other ppls data. Just by changing an nodeid on your clientside script you can get/delete/updates nodes that you shouldnt be able to get to.
Example: Dating site. You have a profile. You log in successfully. But you're a trouble maker so you look into the js lib and find a:
Sounds awsome but how about security?
Hi Matt (who never sleeps),
The docs states that you have authenticate using a User that can modify ex. Members. How do you prevent someone from modifying urls and modify/delete content they shouldent?
Example. If I use this in an Intranet, where my members can login and change or delete their memberinfo I would create a (shared) user account and give it access to the members area. Right?
Isnt it too easy to hack the "DELETE /rest/members/{id}" to delete any member?
All the best
Jesper
I'm sure there must a key authentication in the webservice before methods are called.
Hi Jesper,
Security is actually a real pain, especially when it comes to web services, and especially when it comes to the services existing within a website with it's on security mechanism. The best I could come up with was a custom token based security mechanism. With uRest the first thing you have to do, is request an auth token. This auth token is specific to the credentials you pass, and your IP address. This is then appended to every request, along with your username. Every request is then checked against an umbraco user, and your IP to make sure the request is valid. This isn't the best, but it is better than what comes with the default Umbraco web services.
Unfortunatley, I don't think this is going to help with the example you have given, as yes, if someone was to intercept the request, and execute it within the same IP range, they could indeed just change the id parameter. That said, I would say this is going to be true of more or less any restful interface, really the request should be hidden behind your code so that it's not obvious to your users how it's executing their request. In my opinion, if someone is going to the extend of monitoring their HTTP traffic request to reek havoc with your system, I'm sure they are going to find a way regardless.
Cheers
Matt
Hi Matt,
Any authentication will not solve this. My point is that it's a real danger to use generic webservices to modify data as the logic to deside whether the accessed data "belongs" to you is on the client. Once placed there it's gonna go wrong.
Thats why I really love Umbraco Base as this only is a tool for you to build your own webservices and you can then build your logic serverside.
Best,
Jesper
Hey Jesper,
Can you explain where you see /base being more secure than uREST?
Cheers
Matt
Yup :-)
Say you have some data that belongs to your member profile. You are allowed to work with these data and not others data :-)
Authentication:
In base you have your session authentication and within this you have your current member id stored in sessionmemberid.
Url to serverside base method:
/base/datadelete/id
Pseudo source:
public static datardelete(int id) {
// the deal is that base is only a framework - I have to make my own methods but it's easy. And therefore I can make my data logic serverside.
res = delete from datatable where dataid = id and memberid = sessionmemberid
}
Best,
Jesper
And what if you wanted to call that /base method outside of an umbraco context? You no longer have state, thus no longer have your session, thus no longer have security. In your example, the methods are only made secure because you've previously logged into Umbraco. That's great if all you are doing is proxying back into your site, but uREST is designed for a different problem, and that is connecting and interacting with an Umbraco site, outside of an Umbraco context.
Think iPhone app managing your website, or some other app on a completely different server pushing data directly into your site. In these scenarious there is no session state, and never could be, because they are seperated and it's not a logged in user pysically performing those interactions.
Anywho, I think from your example, yes, /base would probably be the best way, but if you want to open up your site to some other third party app, uREST should offer as good a security mechanism as you can get under the circumstances (take a look at the default umbraco web services, they pass a username and password in clear text with each request).
Cheers
Matt
Hey Matt,
If a third person where to sniff / hack the requests any of the above would be compromised.
My example could be modified to use the token approach. The point is that because I'm not using a general serverside features, I'm able to put in some logic to ensure that any authenticated user only gets to delete his own data. To compare - if I install the general lib, once authenticated, I can delete any node.
Best,
Jesper
Hey Jesper,
I don't disagree, and that is always going to be the case with any "generic" web service layer. The example you've outlined is very specific, and yes, could be made more secure than uREST by using a specialized /base method. But if you were to write /base methods to handle all the scenarios uREST can handle, you are going to hit the exact same security problems.
I think at the end of the day, it's about using the right tool for the job, based upon your needs. If you need the upmost security, and don't mind reinventing the wheel creating your own /base methods every time, then go with /base. If you'd prefer to just plugin a set of pre-built web services that can do EVERYTHING but at the risk of being a little less secure, then choose uREST. To have the choice surely can't be a bad thing.
Cheers
Matt
Hello Matt,
I agree - both has it's strong points and uRest is cool because it can do EVERYTHING :-)
As long as the risks are known to everyone.
Maybe being able to configure the operations allowed in the areas might be very handy. To be able to allow only GET for member and media operations and say no access for rest.
Best,
Jesper
Hey Jesper,
That's not a bad idea to allow the configuration of which methods enable/disable, I'll look to add it in the next version. I knew this convo was leading somewhere =)
Cheers
Matt
Good stuf :-)
And in version 3 you might even be able to configure data ownership checks. That would solve almost everything. Like "has to be logged in", and "profile property compare with data property".
Thanks for listning .-)
All the best,
Jesper
If I can just interject here: nobody can sniff your requests if they go over HTTPS unless there's a proxy server in the middle that does some request spoofing, which you should be able to detect by validating certificates.
Jesper: If someone listens in during login (without using HTTPS), they can just as easily see your credentials and it is just as easy to take over their session.
HTTPS and certificate checking is the silver bullet here. I don't know how easy it is to validate certificates though.
Hi Sebastian,
I'm with you totally. My concerns was never about sniffing/hacking nor authentication. My focus (mayby I explained myself very badly) is on what an authenticated user can do with other ppls data. Just by changing an nodeid on your clientside script you can get/delete/updates nodes that you shouldnt be able to get to.
Example: Dating site. You have a profile. You log in successfully. But you're a trouble maker so you look into the js lib and find a:
/rest/documents/182737/documents?doctypealias=messages
Next thing is changing that 182737 to see if I can retrieve anything.
Best,
Jesper
Aaah, so sorry, I read it too fast then!
Yes, very difficult to solve! The only real solution is relating items to customerId's indeed.
So the only thing I did here, was make it an even bigger security nightmare, whoops! ;-)
You still need a secure channel, otherwise your solution will not help much.
is working on a reply...