On my website, there is a web form that users fill out and the data collected gets e-mailed to me. Is it possible for someone to hack the data and get the users' information? Also, my site does not use a secure connection.
It depends on whether the data is logged, or flushed after being emailed.
If it is logged, then theoretically yes, a malicious user could compromise the server and access the logs.
If it isn't, there's still the possibility of your email being compromised, but at some point a line has to be drawn.
It would probably be helpful to see a specific example, or at least a little more details about exactly how this form operates.
If someone uses your site from say an internet cafe then there could be a man-in-the-middle attack where all requests go through some program sitting on the cafes server.
i think if you are worried then you should probably secure at least that page.
If you are not using SSL then its possible for someone to sniff the traffic to your server and collect all the user information thats being posted from their browser. Using an SSL cert and forcing HTTPS will make it much harder (nearly impossible) to catch the traffic on the netwrok.
Related
I am writing a REST Api gateway for an Angular SPA and I am confronted with the problem of securing the data exposed by the API for the SPA against "data thiefs". I am aware that I can't do much against HTML scraping, but at least I don't want to offer such data thiefs the user experience and full power of our JSON sent to the SPA.
The difference between most "tutorials" and threads about this topic is that I am exposing this data to a public website (which means no user authentication required) which offers valuable statistics about a video game.
My initial idea on how to protect the Rest API for SPA:
Using JWTs everywhere. When a visitor opens the website the very first time the SPA requests a JWT from my REST Api and saves it in the HTTPS cookies. For all requests the SPA has to use the JWT to get a response.
Problems with that approach
The data thief could simply request the oauth token from our endpoint as well. I have no chance to verify that the token has actually been requested from my SPA or from the data thief?
Even if I solved that the attacker could read the saved JWT from the HTTPS cookies and use it in his own application. Sure I could add time expiration for the JWT
My question:
I am under the impression that this is a common problem and therefore I am wondering if there are any good solutions to protect against others than the SPA having direct access to my REST Api responses?
From the API's point of view, your SPA is in no way different than any other client. You obviously can't include a secret in the SPA as it is sent to anybody and cannot be protected. Also the requests it makes to the API can be easily sniffed and copied by another client.
So in short, as diacussed many times here, you can't authenticate the client application. Anybody can create a different client if they want.
One thing you can actually do is checking the referer/origin of requests. If a client is running in a browser, thr requests it can make are somewhat limited, and one such limitation is the referer and origin headers, which are always controlled by the browser, and not javascript. So you can actually make sure that if (and only if!) the client is running in an unmodified browser, it is downloaded from your domain. This is the default in browsers btw, so if you are not sending CORS headers, you already did this (browsers do, actually). However, this does not keep an attacker from building and running a non-browser client and fake any referer or origin he likes, or just disregard the same origin policy.
Another thing you could do is changing the API regularly just enough to stop rogue clients from working (and changing your client at the same time ofc). Obviously this is not secure at all, but can be annoying enough for an attacker. If downloading all your data once is a concern, this again doesn't help at all.
Some real things you should consider though are:
Does anybody actually want to download your data? How much is it worth? Most of the times nobody wants to create a different client, and nobody is that much interested in the data.
If it is that interesting, you should implement user authentication at the very least, and cover the remaining risk either via points below and/or in your contracts legally.
You could implement throttling to not allow bulk downloading. For example if the typical user accesses 1 record every 5 seconds, and 10 altogether, you can build rules based on the client IP for example to reasonably limit user access. Note though that rate limiting must be based on a parameter the client can't modify arbitrarily, and without authentication, that's pretty much the client IP only, and you will face issues with users behind a NAT (ie. corporate networks for example).
Similarly, you can implement monitoring to discover if somebody is downloading more data than it would be normal or necessary. However, without user authentication, your only option will be to ban the client IP. So again it comes down to knowing who the user is, ie. authentication.
I have a web app with a JSONP API I'm using with my iPhone app. How do I secure this so requests from other places won't be able to access my API?
Clarification: My data isn't that important. You don't even have to sign in to view it. I just don't want by my DB to work on queries from other sources.
You have embarked on a very very complicated subject. Prepare yourself for some very long nights of reading various cat and mouse techniques of securing your app. I think your best bet is to put a secret string in the header of each request. Something like this:
Secret-Header: #$F#FQAFDSFE#$%#ADSF())*
Validate that header on the server side and use SSL. Someone could easily respond to this post with "Well that doesn't stop this, this and this" and they will be right. The question is, are you a bank that is worried about someone draining your client's accounts? Or are you just worried about 99.9999% of the population not being willed enough to hijack your junk?
Some people have all kinds of opinions on this, but if your users require authentication to access the web services, just require the username and password to be sent in the header via SSL. They can still hijack your services, but wouldn't be able to see anything that they weren't supposed to anyway. That only works on a user level type of setup though. If it's completely public, you have to consider how unimportant your data is. It may not be as important as you think.
You can embed a private RSA key in the iPhone client and send a signed timestamp with each request.
The server would verify the timestamp against the public key and reject unsigned requests.
The enemy can disassemble the iPhone client and steal the key, and you can't do a thing about it.
(other than a blacklisting arms race)
You can use TLS protocol with client certificate.
http://en.wikipedia.org/wiki/Transport_Layer_Security
The only problem with this solution (not solved today) is that the client certificate is stored in the app binary and can be retro-eenginered.
One traditional way to do this is to take all of the url variables you are requesting, add a 'secret' string, and hash the whole thing and add it as an additional url variable. On your API side, you do the same thing, and if the hash matches what you were given, it's probably coming from your app.
Jeff Atwood argues that we should stop asking users to register on our websites because we should rather use their "internet driver's license -- that is, [their] existing Twitter, Facebook, Google, or OpenID credentials" for authenticating them.
While I am beginning to think that he may be right, I could not yet decide and I am looking for arguments against letting foreign sites gain control over personal web pages.
Do you see any dangers of authenticating users like this?
if you want a more in depth response based from someone who has dealt with this technology before, you should listen to the recent .NET Rocks with Rob Connery which was precisely about this topic.
http://www.dotnetrocks.com/default.aspx?showNum=626
After listening to it I decided to NOT use OpenID on my site.
Here is the link to Rob's blog post on the subject:
http://blog.wekeroad.com/thoughts/open-id-is-a-party-that-happened
Here are a number of reasons why not, although each comes with caveats:
If you only authenticate with one external service, anyone who doesn't use that service cannot use yours.
If your external authentication service goes down, users won't be able to use yours until theirs comes back up; similarly, slowdowns in their authentication server will also affect you.
Requiring users to authenticate with another service requires them to accept that service's EULA, which may be a turnoff for some; similarly, it ties you morally to whatever decisions your authenticating service makes. In particular it can make you appear to be a satellite, spinoff or affiliate of the auth site, since users have to see their logo every time they try to use your service.
The external auth domain gets a perfect snapshot of your viewership, giving them a lot of insight into what your company is doing. Since their analytical tools and staff are generally top-notch, they may conceivably know more about your user base than you do.
The major way to avoid this problem is to allow people to use the service of their choice, instead of a single service. If you are limited to developing one, for development time constraints, using OpenID is the best bet because many other authentication domains also qualify as OpenIDs, and therefore ameliorates most of the above problems.
I think using IDs from any of these big names are ok as long as you don't provide service that needs an endpoint like email, IM etc.
However, OpenID is just not trust-worthy. If you have any doubts, try this OpenID
http://opennoid.appspot.com/anyid
This is a disposable ID that doesn't require a password to login.
I am looking for some suggestions on how to secure access to a RESTful API which initially be used by an iPhone application, but will have other clients in the future. The data exposed by this API must be kept secure as it may contain health information. All access will be done over HTTPS.
I was thinking that I'd like to require pre-registration of the iphones at setup and then also some type of PIN/Password on each request. So, simply knowing the password without pre-registering the phone/client won't provide access. I was thinking about somehow tying it to the iPhone identifier if that is possible, but not sure it would provide any additional security. The iPhone identifier is just another piece of information and it may not even be that secret.
So, some requirements would be:
Use some type of pin-based solution on the iPhone, but want more security then a simple 4-6 digit pin can provide.
No passwords could be sent in the clear.
Not be subject to reply attacks
Having to pre-exchange some data between client and server when setting up client is OK.
I would think that, if the application contains medical records, you would want to have the user authenticate every time they use the application or, at least, have some way of pushing down a disable message that renders the app useless in the case where it is lost or stolen. The 4-6 character password (pin) would also concern me with respect to HIPAA, if it applies.
You might want to treat it as a standard web app from the server perspective and do session-based authentication and access with a session that times out, perhaps after a long period, and re-authentication on timeout.
You could use SSL with client authentication. If a device gets lost, you can remove the certificate on the server. There are some obstacles though:
It is not entirely clear if/how you can do client authenticated SSL on the iPhone Unfortunately, there is not much documentation about it. Have a look at Certificate, Key, and Trust Services Reference
You have to create a private key for every device
You also have to figure out a secure way to transfer the private key to the device
I'm working on a REST service that has a few requirements:
It has to be secure.
Users should not be able to forge requests.
My current proposed solution is to have a custom Authorization header that look like this (this is the same way that the amazon web services work):
Authorization: MYAPI username:signature
My question is how to form the signature. When the user logs into the service they are given a secret key which they should be able to use to sign requests. This will stop other users submitting requests on their behalf, but will not stop them forging requests.
The application that will be using this service is an iPhone application, so I was thinking we could have a public key embedded in the application which we can do an additional signature with, but does this mean we'll have to have two signatures, one for the user key and one for the app key?
Any advice would be greatly appreciated, I'd quite like to get this right the first time.
The answer is simple: It cannot be done. As soon as you ship any solution to the end user, he or she can allways attack the server it is communicating with. The most common version of this problem is cheating with hi-score lists in Flash games. You can make it harder by embedding some sort of encryption in the client and obfuscating the code... But all compiled and obfuscated code can allways be decompiled and unobfuscated. It is just a matter of how much time and money you are willing to spend and likewise for the potential attacker.
So your concern is not how to try to prevent the user from sending faulty data to your system. It is how to prevent the user from damaging your system. You have to design your interfaces so that all damage done by faulty data only affects the user sending it.
What's wrong with HTTP Digest Authentication?
I think the simplest way to do this right would be to use HTTPS client authentication. Apple's site has a thread on this very subject.
Edit: to handle authorization, I would create a separate resource (URI) on the server for each user, and only permit that (authenticated) user to manipulate this resource.
Edit (2014): Apple changed their forum software in the past six years; the thread is now at https://discussions.apple.com/thread/1643618
There is a better discussion of this here:
Best Practices for securing a REST API / web service