Current State :
I am working on a chrome extension. My extension makes a request to my web-server and shows the results fetched.
Disadvantages :
I am exposing my APIs, so any third-party , not necessarily, owner of the extension may make a number of requests on my server. This will allow him access to all my data
This can also lead to my server crash, if the requests are made very frequently via bots.
So, is there any way that can authorize that requests made to the corresponding server handles are via the chrome extension only. Can it be done by setting some cookie and checking them before sending results ?
Thanks !
No, you can not ensure that only your Chrome extension is making the requests. Once your code leaves your control (i.e. the client has it), there is no guarantee that it isn't tampered with or reverse engineered. What you can do though, is make the user log in before accessing your API.
By authenticating, you aren't verifying that the user is using your Chrome extension, but you do have someone to blacklist if your server becomes the subject of large traffic. You can have the user of the chrome extension create an account one time and then the extension can send those credentials to your server with each request.
You may be tempted to try things like embedding a secret token or passphrase, but this will only stop the lazy attackers. Furthermore it may give you a false sense of security. Go with authentication if you are worried about Denial of Service attacks.
Related
Im automating security scans by proxying my UI tests via Zap. For each security scan run, new zap session is created and requests are proxied.
In our App, access token from login api's response is set in authentication header for authentication purpose. When I proxy my tests via zap, headers are also recorded and stored in ZAP along with request payload, url etc.
If
token recorded by zap along with request is still valid during active scan (not expired or not invalidated)
headers are excluded from ascan attack vectors (which is the default setting)
I was assuming I can get active scan work on apis (which require authentication also) without setting authentication, users, forced users, session management etc in Context.
Im not sure how to validate this!
Can anyone help with below
Is my above assumption of "header recorded is good enough for ZAP to ascan" correct in my scenario ? (only payload, params etc will be tampered)
Whats the advantage of setting authentication, users, forced users, session management etc in Context for automated security scan?
Thank you in advance.
Authentication is a pain. A complete pain. There are so many different ways that apps authenticate, and all apps have their own quirks.
If the token remains valid then yes, in theory that should be ok. But how you validate this will completely depend on your app. What does it to if the token is invalid? Will it return 403? You can use ZAP stats to work out if it looks like the requests are authenticated, and if ZAP doesnt currently recored the stats you need then you can add them via scripts.
The advantage of setting authentication etc etc is that when set correctly then ZAP should detect if a token is invalidated (which happens all too often when attacking an app) and can then reauthenticate.
Handling authentication is hard (not just in ZAP, but in all security tools). For more help you're probably better off asking on the ZAP user group: https://groups.google.com/group/zaproxy-users
Also have a look at the ZAP in Ten video seried - esp the ADDO Workshop ones where I go into authentication in a lot more detail: https://www.alldaydevops.com/zap-in-ten
I've setup security in my RESTFUL WCF services using Custom Basic Authentification (thus desactivating the iis Basic Authentification and not using Windows Accounts Login at all; my service is hosted by iis) using the following link.
blog link
I understand the consumers have to implement a client to pass credentials in the request header.
It is 64bits based encoded and we can see credentials passing in firebug network tab while debugging (it is always the same string encoded <=> same credential .......)
So, in addition, to enforce security I will add SSL to encrypt the url :
https://myrestfulserviceurl.com/Method
Now the consumers ask me why we don't just put the login and password in the url request i.e
https: // myrestfulserviceurl.com/Method?login=XXX&password=YYY
(also combined with SSL)
Thus the change requires to add login and password as parameters in my Operation Contract and call a method for authentification in my method "Method".. etc etc
My question is :
What is the difference (both scenarii will use ssl) between Custom Basic Authentification (credentials in request header) & simply passing credentials in url in param ?
I mean : I'm just asking myself why I do bother to implement Basic Authentification. Passing credentials in url or in header look similar : it's passing stuff in the request. But talking in term of security, it looks the same ?
Basic Authentification looks not more secure excepted the 64bits based encoding.
Correct me if i'm wrong.
I am just looking a reason why implementing Custom Basic Authentification.
Any idea/advise?
Thanks
The main difference that comes to mind is to do with how visible the data is and how long it is likely to be retained.
For instance, assuming SSL is terminated at your application server, values in the get parameters are likely to be automatically logged to your file system (in request logs for instance). Having usernames and passwords in there is not ideal as it makes it much easier for them to be leaked.
If SSL is terminated at a loadbalancer or some similar proxy, then the usernames and passwords could be saved in request logs on servers you may not be thinking about and probably have less control over.
By contrast, the Authentication header is much less likely to be logged to places you're not expecting.
I thought about doind this myself and decided against it because i wanted the Restful URL's to focus only on the operations and keep security out of it, for example I might want to re-use the same code on a different application.
Also Im not sure but i think there could be a security implication concerning replay attacks, if someone obtained the link then they could execute it in any http client. If you used the authroisation attribute in the http header you could avoid this by putting an expiration on it. Also i think its better to hide this information from the html page body.
The dude who wrote this http://lbadri.wordpress.com/2012/07/30/anatomy-of-a-simple-web-token-swt/, which is taken from his book "Pro ASP.NET web Security". Gives a pretty decent example of creating a token which you could then use in the http header "Authorisation", like: Authorization: Basic d2FsaWRAGssSGZ21haWwuY29tOn236dhbGlk
When running with Kerberos tickets, I have noticed that every firefox request has a different Authorization line in the HTTP header. I loaded a simple page, then hit the reload button several times and it was never the same. What causes this behavior? I would have thought that the Authorization line would stay constant for the duration of the Kerberos credentials. (Note that I got the credentials via the kinit command before firing up firefox.)
When the authentication method is Basic, then firefox continues to send the same base64 string of 'user:password' every time. This is the behavior I expected.
Any ideas?
mmm it is odd. Any chance that you can post snipptes of the wireshark output. One possibility is that the Service Ticket obtained is not cached and FF gets a service ticket. There have been implementations where a client will get a service but not cache it, instead go and get a service ticket every time needed. Sometimes it is because the process may not have write permissions and it is relatively an inexpensive operation ( a single round trip and symmetric encrypted data)
This is due to various limitations in both HTTP and in how Negotiate-Auth works.
HTTP was originally designed as a stateless protocol, and HTTP's authentication system assumes that model. It was designed to do a full authentication exchange in each request; for example, with Basic, it's enclosing your full credentials in each request. With Negotiate-Auth and SPNEGO, the same thing is true: a brand new GSS-API context is created and a fresh authentication is performed with each request.
Yes, this is very wasteful. But there (currently) isn't any standardized way to authenticate once, establish a session, and then bind all subsequent requests to that session (the way that, say, IMAP, POP, or ssh does). There is some IETF work in this direction, but it's very preliminary.
The ticket is cached; it's not doing that much work each time. But the server and the client go through the whole GSS-API session dance each time.
I may not be going about this in the best way possible, but as a school project, I'm in a group where we are developing a system to handle checking in and checking out of dorm rooms and handling any charges that may arise because of damages to items in the room. We are digitizing the project and putting in on the web and writing a native iPhone app (part of the assignment, I'd rather just make it a universal web app, but oh well). For the iPhone app, we're putting together a web API but I'm having some doubts about our attempts to keep the API secure.
Our process right now is a call to the API to log in with a username and a password hash, if it was a successful login, an Authentication Token is generated and returned to the iPhone in XML along with various other data. Each subsequent request requires this AuthToken. A user can either sign out, or if there's inactivity for 20 minutes, the AuthToken is destroyed server side. But this leaves the API open for the "Pass The Hash" attack where anybody listening in on the request can get the password hash out of the query string. Anybody with Wireshark and a simple filter can wait for somebody to sign in when everybody would be moving into the dorms and be able to manipulate just about anything.
Every single request is susceptible to the Pass The Hash attack. When logging in, the username and password can be repeated later to obtain a different AuthToken. Not only that, any already generated AuthTokens could be used and the session extended without the real user knowing.
I have thought of the idea of tying the AuthToken to an IP address and rejecting requests that use a valid AuthToken from an alternate IP address, is this reliable or will the iPhone be jumping IP addresses when on the cell network instead of Wifi? I want to give any malicious users a hard time, but obviously not legitimate users.
The project is still in the early stages so now would be the time to make drastic changes to the API like this. Any tips on securing a web API would be awesome.
Your best bet would be to send everything over SSL. That will prevent anyone listening to the wire and sniffing either the password hash or the authentication token.
You should also consider sending a nonce to the client that gets hashed along with the password to prevent replay attacks.
It's also pretty easy to change the authentication token on each request. This prevents both replay and session-fixation. Just make sure the tokens are good random numbers.
You need to use HTTPS.
Most anything on HTTP is susceptible if you include people using Wireshark. HTTPS encrypts all traffic between the client and the server and will prevent most packet sniffing attacks.
I have REST services that I was planning on protecting with Windows Integrated Authentication (NTLM), as it should only be accessible to those internal to the company, and it will end up being on a website that is accessible by the public.
But, then I thought about mobile applications and I realized that Android, for example, won't be able to pass the credentials needed, so now I am stuck on how to protect it.
This is written in WCF 4.0, and my thought was to get the credentials, then determine who the user is and then check if they can use the GET request and see the data.
I don't want to force the user to pass passwords, as this will then be in the IIS log, and so is a security hole.
My present concern is for the GET request, as POST will be handled by the same method I expect.
One solution, which I don't think is a good option, would be to have them log into Sharepoint, then accept only forwarded reqests from Sharepoint.
Another approach would be to put my SSO solution in front of these services, which would then force people to log in if they don't have credentials, so the authentication would be done by SSO, and since the web service directory could be a subdirectory of the main SSO page, then I could decrypt the cookie and get the username that way, but, that would be annoying for the mobile users, which would include the senior management.
So, what is a way to secure a REST service so that it is known whom is making the request so that authorization decisions can be made, and will work for iphones, android and blackberry smartphones.
I have the same problem so let me give you the details and would also appreciate feedback. Since you are using an internal system you have one extra option that I have listed.
My first option isn't perfect, yes it could be hacked but still - better than nothing. With each request you pass the device's unique identifier along with a hash. You generate the hash using a salt embedded in the application along with the id. On the server you match the incoming hash with one you generate at the server, with the passed unique identifier. If someone "roots" their device, and is smart enough they could find the salt - you can obscure it further but ultimately it could be stolen. Also, I keep all requests on SSL to just help hide the process. My "enhancement" to this process is to pass back new salts after each request. New devices get 1 chance to obtain the next salt or get locked out ... not sure about that step yet.
Now another approach, is to have the user enter a "salt" or username and password only an internal user would know - the device obtains a token and then passes it (on SSL) with each request. Nobody outside your company could obtain that so this is probably best. I can't use this since my app is in the app store.
Hope that helps! Let us all know if you ever found a good solution.
My current solution, in order to protect data in the system, is to force people to first log in to the application that the REST services support (our learning management system), as I have written an SSO solution that will write out a cookie with encrypted data.
Then, the REST service will look for that cookie, which disappears when you close the browser, and I don't care if the cookie is expired, I just need the username from it, then I can look in a config file to see if that user is allowed to use that REST service.
This isn't ideal, and what I want to do is redirect through the SSO code, and have it then send the person back to the REST service, but that is not as simple as I hoped.
My SSO code has lots of redirects, and will redirect someone to a spot they pick in the learning management system, I just need to get it to work with the other application.