I've been looking into using Web API for a new product I'm developing; the initial version will be a web application followed up by mobile/tablet applications so the Web API route seems a good one.
I've read a lot about securing Web APIs using cryptography and SSL, however one thing I'm not too clear on is where to call the Web API from.
If I'm using private cryptography to create an authentication token it seems to make sense to create the HTTP request using ASP.NET leveraging HttpClient etc. as the web server will have a private encryption key so the Web API which will have a corresponding private key will know the request came from the website.
This makes sense going forward as a mobile/table app will have a separate key etc.
Sounds silly, but it seems to me that the browser client cannot do the encrypting as the private key would be visible to the user relatively easily and they could take that key and use it elsewhere, (mobile/tablet clients would be able to do the encrypting as the key could be embedded).
Fair enough, but if I'm posting back to my web-server to do the encrypting I'm essentially sending the details of my request to the server un-encrypted, so someone could take the request sent to the web server, change it and the server would encrypt and send the changes to the Web API.
Is there a way to send encrypted Web API requests from the client (javascript) without revealing the key? Am I right about the server requests? will SSL sort out that problem?
I think I'm confusing myself slightly with all the information out there about securing Web APIs, any clarity would be welcome!
Related
I wanted to know how I can do that only my android application, developed with native react, can access my API node js. So my server will be accessible only from my site, using a simple whitelist of domains, and from my app
There is no way to guarantee this. A client controls everything that happens on client side. If an application contains protection mechanisms against client interference, it can be reverse-engineered.
A way to protect unauthorized clients from connecting to the backend is make backend requests with API key that is transmitted as encrypted (hashed) string and verified on server side. Abused API keys need to be blacklisted.
Since hashed keys can be extracted from API requests, a way to make this more complicated is to make hashed API key dependent on specific requests, e.g.:
fetchData(url + '&api_key_hash=' + md5(SALT + url + SECRET_API_KEY))
api_key_hash still can be verified on server side but is useless for a client who wants to get unauthorized access to backend API. The only way for a client is to get SECRET_API_KEY.
Since client application can be reverse-engineered to get unencrypted API key, a way to make reverse engineering more complicated is to not store the key as plain string and obfuscate the application.
Note that while these measures don't guarantee that the application won't be reverse-engineered to extract API key, obfuscation can complicate things for application developer, e.g. debugging and analyzing crash reports. To my knowledge, reverse engineering of React Native application that doesn't make use of any protection besides JS obfuscation is trivial.
I have been learning angular 2 and have been doing research on how to protect data within my app.
How, if possible, can you obstruct data from the front end of the app? Is it possible to serve the angular app through a node server, say using Universal Angular, which would mean variable values can be hidden from the user on the front end.
I am essentially looking for the solution of hiding private keys which will give the app access to various APIs/creating auth headers/paths. I've read a solution is to have an API bridge for the app - so I would connect to that to retrieve the data/keys - but then how do I protect that from access? Since that endpoint would then be exposed and could be abused, or if getting keys the response is visible. The idea of locking down to domain I have read is unreliable due to spoofing and locking to IP wouldn't work as its front end or through an app?
I feel there is a glaringly obvious answer that I am missing something.
You must assume that everything that is held in your frontend is visible to anybody that can access your frontend.
All JS variables, storage (local, session), network requests, etc. in your front end are unsecured from users of your frontend.
You can (and should) use SSL to make hide data from anybody in between your server and the browser, but there is just no way to secure data held in your frontend from users of your frontend. (At least if your frontend is available on "regular" browser as opposed to some tightened kiosk mode installations.)
It's simple, when the server sends the data as response to a request, then the data can be accessed from the outside.
If you don't want that, then don't send the data.
You didn't mention what problem you actually try to solve. For API keys you can for example do the request to the API on the server and provide an API on your own server for your clients and then make the server forward the requests to the actual API server.
I would like to encrypt ajax post and get request with javascript.
The flow should be -
Server generated private and public key on request
Server sends the public key to client
Client encrypts the data with public key
Sever decrypts the data with the private key
I know SSL is an option, but my application is a small plugin which can be installed on any website that allows a user to purchase products on that website. Is there a way i can encrypt all the data at front end and decrypt at back end.
Thanks in advance!
Generally speaking, in browser cryptography can be considered a bad idea. Sending the data over ssl-tls would likely be much more secure than a home-brewed crypto solution, like you seem to be suggesting. This can be considered especially bad when transmitting data like credit card info, as it appears you will be.
http allows for extremely easy man in the middle attacks to eavesdrop on any data being sent either way, so there would almost certainly be no secure way to transmit the keys in the first place, let alone the secure information.
If you really really want to go this route, then have a look at crypto-js.
This is not a good idea, and you should use SSL. Probably hence the downvotes.
Considering your use case, the best way to do this would probably be to host your own central service with SSL enabled, and route all ajax requests to your service, not theirs. Their servers could then poll your server using your SSL certificate, to view any relevant information. So you would be acting as some sort of centralised API, with both the clients and businesses connecting. You still need to consider however, that any information sent in the clear, ie over http, not https, can be tampered with before it reaches the user.
As far as I am aware, no, you cannot generate SSL certificates on the fly.
I'm working on a web app that is mostly static - just HTML/CSS/JS + assets. I'm using a Rack server (Thin, actually) to serve it.
While the app is mostly static, there are a couple of server-side needs that have cropped up along the way. Since the app needs to interact with those needs via JavaScript, I've added Sinatra to the stack to allow me to easily set up some routes to serve as a simple API.
One such API call is to send an email - the web app needs a way to send an email to users. I set up a route (/api/mail) that can be called with a POST that includes a JSON object, and Ruby will fire off an email (via SendGrid).
Here's my issue - by nature, these API calls are public. Most of the time, that is fine - but with the email API, I want to protect it so that nobody can just start sending malicious emails with a simple POST, posing as my app.
Problem is, I'm not quite sure how to authenticate this. The web app itself is the client, not the user, so a password or API key seems worthless, since anyone could just sniff out the POST header and grab the credentials that the app is posting to the API.
Is encrypting everything via SSL my only option, or am I missing some glaringly obvious solution?
At the end of the day, anything you do can easily be scraped. I would do some aggressive rate limiting by ip and session, don't think if anything else would be possible (or effective)
Is there a norm for AJAX security?
When making an XMLHttpRequest, if querying an HTTPS url, will the browser handle all the certificate business and properly encrypt the request (or use an already existing authenticated tunnel)? Are there any security flaws in this model?
Then there's also user authentication issues with AJAX. This made me think that using the user's password to encrypt part or all of an AJAX request could solve some authentication issues. I've seen some impressive javascript based encryption tools. It seems like there'd be lots of potential there to build a single system that takes care of both encryption and authentication(host level and application user level). I have however not seen anything that seems 'tried an true'.
My question can be summed up as:
Is there a norm for secure AJAX either
using browser technologies or client
side javascript? What
is it? And if not, what's preventing
us from building one using javascript?
Thank you, as always.
SSL through HTTPS is sort of a cooperative venture with the destination server. The destination server will report its identity with its identity certificate (sent back to the client). This is part of the protocol that will encrypt the data stream between the client and the server.
However, this just encrypts the stream, it does nothing about several other security issues. Identification and authentication of the user entity making a request is handled through other means. If you're encrypting the stream with SSL, it should be safe to use HTTP basic auth. After that, the response to authentication should be a session id sent back to the client that will pass it back on all subsequent requests. Application servers typically manage the creation of those session ids.
Ajax does not inherently introduce new
security vulnerabilities in the realm
of web applications. Instead, the
applications face the same security
issues as classic web applications.
Unfortunately, common Ajax best
practices have not been developed,
which leaves plenty of room to get
things wrong.
from: http://www.securityfocus.com/infocus/1868
Basic authentication makes sense. I found this article explaining how to do it.
I somehow still have this desire to not use all the browser technologies and encrypt/authenticate things myself. Not sure if that would make any sense. Key caching would be hard to accomplish.
I'm still looking to find out if this (SSL + using basic auth in ajax calls) is the norm.