I have a basic html, which contains a form. This form submission is handled by a RESTful backend api service (written in spring boot). The html page is unprotected for business reasons -any sort of authentication / login mechanism can't be applied on the HTML. How can I make sure, only the html is allowed to hit the backend APIs, and not other sources? Both the html and backend apis are under the same domain. Example - example.com/index.html; example.com/getStudentList
How can I make sure, only the html is allowed to hit the backend APIs, and not other sources?
If I'm understanding things correctly, you don't want consumers of your API to authenticate with the API, because reasons? But what you want is that any client that loads the index page can access the API.
The closest implementation I can think of that would work at all like that would be to treat the API urls like a one time pad: You dynamically generate the html page, with urls that include some difficult to guess token. When the API receives any request, it checks the token -- if there is no token, it rejects the request (403 - Forbidden). If there is a token, it checks whether or not that token is still active; if the token is expired, then the request is rejected. If the token is inactive, but within some grace period, you might redirect the API request to a URL with a newer token (301 - Moved Permanently). If the token is active, then you serve the request.
Mark Seemann, while trying to solve a different problem, wrote a nice little introduction: Avoiding Hackable URLs.
If that sounds to you like a session cookie -- well, you aren't far wrong. To be completely honest, I suspect that the differences are subtle, and I wouldn't be surprised to discover that I exaggerate them. The primary differences are that we are communicating things like cache invalidation and the resource lifecycle explicitly to intermediary components. The Cookie header, on the other hand, is effectively opaque.
This answer is certainly imperfect -- anybody who happens to guess the currently active URL is going to be able to access the API whether they hit the index page or not. Obscurity, rather than security.
But it might be enough to tide you over until you have reasonable requirements.
Related
I am writing a REST API using Express Js and I have some questions regarding security.
My first question is what information can hackers get from a request made from the client side. Can they figure out the request link? What about the body and headers? Is body more secure than parameters/vice versa?
My second question is if I implemented a CORS whitelist that only allowed origins that I wanted to access my API, would that prevent anyone else from hitting the API endpoints? Can people find ways around CORS?
When a REST api is called from a browser client, everything should be treated as completely open. Anyone can read urls, headers, bodies, etc. There is no reasonable way around this, and you should design your system with this in mind.
CORS does not prevent someone from writing a script to call your API either. CORS does not add security, it takes it away by making it possible to call your API from browser applications on other domains. Not having CORS technically makes it harder to call your API in some contexts, and removes a potential security concern. The S in CORS stands for 'sharing', not 'security'.
Any security you need should be based on the server. For example, if you have data in your API that can only be read 1 user, then the server needs to make sure that a different user cannot read it. To do this, a user needs to authenticate itself.
We have a REST style API and try to follow the REST principles as close as possible, so of course that includes statelessness as well.
While the most part of our backend is indeed stateless, there is one thing that seems impossible to achieve, and that is dealing with authentication of non API related static resources. I understand that there are means to achieve stateless auth using some token based approaches (e.g. JWT). But that requires setting some headers or transferring credential information in the requests' message body.
This would be no problem when only API requests have to be secured, as we easily can modify XHR or fetch requests accordingly.
But the problem is that we also need to secure static resources like images and audio/video files. For images I could load them via XHR/fetch, though this is already quite cumbersome compared to using a plain image tag.
But as soon as it comes to html5 video/audio, I haven't found a way to achieve this, is it possible at all?
Currently we just use a secured httpOnly cookie, so in that case it is no problem with either images or audio. May using a cookie (having a JWT like payload) generated by the client could be a solution? Of course this would open another potential security issue since now - in case of a XSS breach - the cookie and its information could be stolen which is impossible with a httponly cookie.
Any ideas to achieve a pure stateless authentication that also works for images and html5 audio or video (and that is not less secure as well)?
PS: HTTP Basic Auth is not an option for various reasons.
No ideas? Hmmm. OK so maybe I can answer my own question ...
A potential solution would be to use something like a JWT, but still use a
cookie as the transport mechanism. So the token is generated on the
server, and set via cookie, just like it has been before with the traditional session cookie. Seems like I could have the "best of both
worlds" with this approach:
The client still has no means to access the contents of the cookie,
and therefore does not need to know anything about authorisation. The only thing the client has
to know is the concept of authentication, i.e. asking the user for the
credentials and sending them to the server as soon as a 401 is
returned.
The server is now freed of doing any session management, all it has to do
is validating the token.
And, most importantly: this will work not only for requests where I can manipulate the header and/or message body (like with XHR/fetch) but for any type of static resource as well, including images and html5 audio & video
Does this sound like a good solution? Vote up this answer if you think it is! Thank you.
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.
Say you're developing an application which consists of a backend HTTP API, which serves a frontend UI. The UI, upon being rendered on the client's browser, will need to make certain calls to the backend (e.g., fetch data for views). However, all these calls are can be checked on Chrome's developer console, for example. This exposes my application's overall logic and internal API endpoints.
Is this a concern for a web application? I looked around some other websites (e.g., Reddit) and I was indeed able to check an API call was being made and I even managed to reproduce it via cURL, getting the same response back.
My first idea to solve this would be to encrypt all data and have it decrypted internally in the frontend app. However, I don't think this would provide much security since the private key would have to be hardcoded in the app's source code, which can also be checked by modern browsers. Besides, this could greatly impact the application's performance.
The best I could think of was to somehow assign a token (JSON Web Tokens, maybe?) to the session (which in turn is assigned to a user). This token would be needed to make the API calls, and maybe it could have a short expiration time. However, the token can still be seen in the HTTP request.
Any ideas?
I am using bcrypts => https://www.npmjs.com/package/bcryptjs + jsonwebtokens in my MEAN app for the same. Bcryptjs creates a salt at the server side and send an encrypted token to the client. The same token is used for API calls. This makes decoding a bit harder for any phishing attempt.
Use HTTPS instead. => Are querystring parameters secure in HTTPS (HTTP + SSL)?
Although I "think" I understand it I need some clarity. With PURE Restful authentication, things do get a bit unwieldy and using forms helps a lot with the UI of the application (i.e., get to have separate login page, forgot password links, easier logout? etc.,)
Now Forms come along and some folks say "not restful" - what is "not restful" about them? Is it that there is no corresponding login resource so to speak? Or does it force something else that I'm missing?
Note: If ones create sessions with them, that's a different matter altogether. I'm more keen on know "why" are they branded as restful? Just googling for "Form based authentication vs restful authentication" throws up quite a few hits.
One could use these "forms" to authenticate and pass on tokens for the application to store in cookies etc., which I feel is entirely restful (assuming cryptographic security etc.,)...
There is nothing wrong with sending your credentials, perhaps through a form, for authentication. The problem is most Form based systems rely on sessions, thus requiring you to only log in "once".
Sessions are server state, thus violating the stateless constraint of a REST architecture.
If you have to send the credentials each time, you can either include them in the payload (i.e. using a form), or you can use the HTTP Authorization header.
If you include them in the payload, you can include them in the body, but only for a POST or PUT, and not a GET or DELETE (since they don't have bodies).
If you include them in the URL as part of the query parameters, then the URL is no longer necessarily representing the actual resource. One of the other tenets is that the URL matches the resource. Adding out of band information (such as credentials) within the query parameters muddies that constraint up a bit.
So, for a REST system over HTTP, you're better to use the existing HTTP Authorization mechanism than working out something else. You could also use client specific SSL certs as well, that works fine also.
Excellent question. I think that RESTful purists will likely say that having a URI associated with an action rather than a resource is what makes form-based auth not RESTful, which is something you pointed out yourself.
Honestly I think that the idea of a 100% pure RESTful application is somewhat of a Utopian ideal when it comes to web applications. I believe it is achievable, however, for RESTful web services, since the calling applications can pass credentials with the request header.
At the end of the day, I think that as long as your application works it is fine, and you should not worry about whether or not it is purely RESTful.
That's my $0.02.
From this answer:
To be RESTful, each HTTP request should carry enough information by itself for its recipient to process it to be in complete harmony with the stateless nature of HTTP.
It's not that form-based auth is not RESTful — it's not RESTful to have a session at all. The RESTful way is to send credentials with every request. This could easily be eavesdropped upon, however, but HTTPS/SSL/TLS closes that hole.
Form-based authentication does not use the authentication techniques that are built into HTTP (e.g. basic authentication, digest authentication).
REST purists will ask you to use the functionality built into HTTP wherever possible. Even though form-based authentication is extremely common, it is not a part of the official protocol. So the REST purist sees form-based authentication as an instance of "building functionality on top of HTTP when that functionality already exists within HTTP itself."
Now Forms come along and some folks say "not restful" - what is "not restful" about them?
The authentication credentials are not in the standard place.
REST doesn’t eliminate the need for a clue. What REST does is concentrate that need for prior knowledge into readily standardizable forms. -- Fielding, 2008
RFC 7235 describes the Authorization header; that gives us a standard way to distinguish authorized requests (which have the header) from anonymous requests (which don't have the header).
Because we can distinguish authorized and anonymous requests, general purpose components can do interesting things.
For example, if the origin server is restricting access to a resource, we probably don't want a shared cache to be re-using copies of the HTTP response to satisfy other requests. Because the authorization has a standardized form, we can define caching semantics that restrict what a shared cache is allowed to do.
Putting the same information into a cookie header, in effect, hides the authorization semantics from general purpose components.
(This is somewhat analogous to using POST requests for safe requests -- general purpose components can't distinguish semantically safe POST requests from semantically unsafe POST requests, and therefore can't do anything intelligently take advantage of the safe handling).
If we had smarter form processing -- form input controls that copied information into the Authorization header instead of the query string/request-body -- then forms would be fine. But (a) we don't have that and (b) we are unlikely to get it, because backwards compatibility.