I have a webpage to let people fill in a form and submit it. This submit is a HTTP POST request to my backend. For the sake of security, I want to keep a whitelist of devices that I consider their submitted information "safe". So I realize I will need to find a way to get some kind of "unique device ID" to identify what device made this POST.
Thanks in advance!
A browser or other client presents itself in the HTTP request with the header User-Agent, and it can be forged easily. Relying on it for whitelisting would be a gap in security. (Cookies can be forged, too.)
However, if you trust some IP addresses, you can whitelist them.
Related
I am a total newb to API and json so this might be basic. But couldn't find a solution by googling.
I want to change e-shop order status via API by clicking a hyperlink in an e-mail.
I activated an API and managed to change the order status by Postman by following command:
PUT {url}/api/v2/orders HTTP/1.1
Content-Type: application/json
Authorization: Basic {abcdefgh}
{
"orders": [
{
"order_number": "00001",
"status_id": "16",
}
]
}
Is there a way how to run this command by simply clicking a hyperlink?
And should I be concerned about security since the authorisation is hardcoded there?
CHeerS!
Email clients for safety reasons do not support the execution of scripts or anything else other than a GET request. As this would require the use of javascript/jquery to build up a payload and call the API with said payload.
You will need to take the client to a secure page to sign in and manage their order.
The hyperlink can perhaps take them to a sign-in page or register page.
Token authorization might work with email being the verification taking the user to a page to see their orders. But again, you won't be sure an authorized person opens the email.
Regarding hard coding any type of authorization, that is a big no.
Since clicking a hyperlink in an email is the same as typing out the address in the browser bar, you can't make POST requests through it. One way of doing what you want is to generate a onetime-use token, and simply put it in the url. When the user clicks the kyperlink, the GET request to the server will contain the token, which can be used for validation.
Is there a way how to run this command by simply clicking a hyperlink?
Not in general, no. Clicking on a link in an e-mail issues a GET request, which can't contain a body. That is: your "orders" JSON won't be included. It also won't know to include the Authorization header.
As far as I know, no common e-mail clients allow you to issue PUT or POST requests.
So: could you encode the request in the URL, and use a GET request instead? Absolutely you could. Don't do this.
There are several reasons for this. The most important is the one you mention:
And should I be concerned about security since the authorisation is hardcoded there?
Hardcoding authorization is a bad idea in general, but particularly in an email: (1) you can't guarantee that an email is encrypted, which exposes the credentials to anyone who can capture the message; (2) if you forward the email to me, I now have your credentials.
Moreover, if you include the authorization in the URL, that's now in the user's browser history, and if they share the link with anyone ("hey, look at this deal on paperclips!"...), well: same as above.
I've built a stateless, JWT-based user authentication system on my web server, following the example of Stormpath (https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage).
The setup seems pretty secure against CSRF, but I'm wondering what about the GET requests.
I was able to model a CSRF attack on GET request by including an <img> tag on a page from a different domain. The server responds to the request with a full page with 200 status. While I don't change any data on GET requests, the pages may still contain some sensitive information, for example, <img src="https://example.com/account" /> may give out user's details, and or <img src="https://example.com/logout" /> could simply do something annoying, and I think there can be more examples.
Is this <img> attack considered harmless, because the browser will not disclose the repsonse it gets? Are there any other tricks with abusing HTML tags that could lead to disclosure of sensitive information by revealing the server output to a GET request?
I'm thinking to additionally include a hash of my JWT access token to the GET URL and have the server require that GET requests include that hash, and it must match the JWT token from the cookie. In this way the attacker will not be able to guess a valid GET URL, while also leaking such GET URL will not allow the attacker to get access to my server because he doesn't know the original JWT from cookies. Apart from minor usability issues, this setup looks like a good idea to me, but I haven't googled out anything similar, so I'm suspicious :)
Concept of CSRF attack, it forces the authenticated user to perform unwanted actions on a web application to which he is authorized to.
CSRF attacks ensures to introduce the state change for stateless servers, thefting of data is not involved as GET request would fetch the response to the victim not to the attacker, as victim is authorized to. There is no means that attacker can see the response to the forged request.
A CSRF attack can bring the change to the state of the server but it can't see their results, it is forced to act blindly.
Let's say, CSRF attack can tell the victim browser to request victim bank account balance, but the attacker can't see that balance. This is obviously a pointless attack.
But it is not pointless if, the attacker ask the victim browser to perform transfer of money from victim account to the attacker's account. The success or failure page for the transfer is inaccessible to the attacking script. Attacker is not concerned about the response of success or failure, his main concern lies he want money in his account.
If you are performing GET request to change the state of the server, it may turn out to be risky for you.
"GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1", if one such is your request.
Which I believe it would not be.
So you must focus on POST request which should be monitored using CSRF token.
Sharing the link for OWASP rules https://www.owasp.org/index.php/Top_10_2010-A5-Cross-Site_Request_Forgery_%28CSRF%29 must go it once.
Is there a way to include additional request headers in form data, other than action and method? I am hoping to send some authentication credentials cross domain without making the user re-enter their login credentials. ie I want to build an Authentication header directly from form submission.
The domain is SSL enabled, so I considered including credentials in the URL, but as explained here this is a bad idea, as those credentials may be secure over the connection, but can be accessed through the browser by other apps potentially.
Larger Picture
I have access to the cross domain username and password through an AJAX request to the client server (home domain). I want to take those credentials and submit them through a non-AJAX request, so a user can download a document securely without the URL being publicly accessible.
To the specific question, I believe the answer is no - you can't control sending any extra headers from the form itself. There are some other things you can send with a form, but they are not useful to what you want to do: W3 Form Tag Specification
What you could do is do a form POST, which is the standard way to communicate when sessions cookies are out of the question and a query string won't do; just use a hidden field with some sort of token/hash of the credentials. Avoid clear-text of passwords like the plague, and really try to avoid reversible encryption of them too. This is just one of those areas you have to be extra careful to avoid creating an easily exploitable security vulnerability.
But generally speaking it works just fine, and anything that can do an AJAX GET should be able to do an AJAX POST.
I've seen articles and posts all over (including SO) on this topic, and the prevailing commentary is that same-origin policy prevents a form POST across domains. The only place I've seen someone suggest that same-origin policy does not apply to form posts, is here.
I'd like to have an answer from a more "official" or formal source. For example, does anyone know the RFC that addresses how same-origin does or does not affect a form POST?
clarification: I am not asking if a GET or POST can be constructed and sent to any domain. I am asking:
if Chrome, IE, or Firefox will allow content from domain 'Y' to send a POST to domain 'X'
if the server receiving the POST will actually see any form values at all. I say this because the majority of online discussion records testers saying the server received the post, but the form values were all empty / stripped out.
What official document (i.e. RFC) explains what the expected behavior is (regardless of what the browsers have currently implemented).
Incidentally, if same-origin does not affect form POSTs - then it makes it somewhat more obvious of why anti-forgery tokens are necessary. I say "somewhat" because it seems too easy to believe that an attacker could simply issue an HTTP GET to retrieve a form containing the anti-forgery token, and then make an illicit POST which contains that same token. Comments?
The same origin policy is applicable only for browser side programming languages. So if you try to post to a different server than the origin server using JavaScript, then the same origin policy comes into play but if you post directly from the form i.e. the action points to a different server like:
<form action="http://someotherserver.com">
and there is no javascript involved in posting the form, then the same origin policy is not applicable.
See wikipedia for more information
It is possible to build an arbitrary GET or POST request and send it to any server accessible to a victims browser. This includes devices on your local network, such as Printers and Routers.
There are many ways of building a CSRF exploit. A simple POST based CSRF attack can be sent using .submit() method. More complex attacks, such as cross-site file upload CSRF attacks will exploit CORS use of the xhr.withCredentals behavior.
CSRF does not violate the Same-Origin Policy For JavaScript because the SOP is concerned with JavaScript reading the server's response to a clients request. CSRF attacks don't care about the response, they care about a side-effect, or state change produced by the request, such as adding an administrative user or executing arbitrary code on the server.
Make sure your requests are protected using one of the methods described in the OWASP CSRF Prevention Cheat Sheet. For more information about CSRF consult the OWASP page on CSRF.
Same origin policy has nothing to do with sending request to another url (different protocol or domain or port).
It is all about restricting access to (reading) response data from another url.
So JavaScript code within a page can post to arbitrary domain or submit forms within that page to anywhere (unless the form is in an iframe with different url).
But what makes these POST requests inefficient is that these requests lack antiforgery tokens, so are ignored by the other url. Moreover, if the JavaScript tries to get that security tokens, by sending AJAX request to the victim url, it is prevented to access that data by Same Origin Policy.
A good example: here
And a good documentation from Mozilla: here
If your API and Website making ajax calls to that API are on the same server (even domain), how would you secure that API?
I only want requests from the same server to be allowed! No remote requests from any other domain, I already have SSL installed does this mean I am safe?
I think you have some confusion that I want to help you clear up.
By the very fact that you are talking about "making Ajax calls" you are talking about your application making remote requests to your server. Even if your website is served from the same domain you are making a remote request.
I only want requests from the same server to be allowed!
Therein lies the problem. You are not talking about making a request from server-to-server. You are talking about making a request from client-to-server (Ajax), so you cannot use IP restrictions (unless you know the IP address of every client that will access your site).
Restricting Ajax requests does not need to be any different than restricting other requests. How do you keep unauthorized users from accessing "normal" web pages? Typically you would have the user authenticate, create a user session on the server, pass a session cookie back tot he client that is then submitted on every request, right? All that stuff works for Ajax requests too.
If your API is exposed on the internet there is nothing you can do to stop others from trying to make requests against it (again, unless you know all of the IPs of allowed clients). So you have to have server-side control in place to authorize remote calls from your allowed clients.
Oh, and having TLS in place is a step in the right direction. I am always amazed by the number of developers that think they can do without TLS. But TLS alone is not enough.
Look at request_referer in your HTTP headers. That tell you where the request came from.
It depends what you want to secure it from.
Third parties getting their visitors to request data from your API using the credentials those visitors have on your site
Browsers will protect you automatically unless you take steps to disable that protection.
Third parties getting their visitors to request changes to your site using your API and the visitors' credentials
Nothing Ajax specific about this. Implement the usual defences against CSRF.
Third parties requesting data using their own client
Again, nothing Ajax specific about this. You can't prevent the requests being made. You need authentication/authorisation (e.g. password protection).
I already have SSL installed does this mean I am safe
No. That protects data from being intercepted enroute. It doesn't prevent other people requesting the data, or accessing it from the end points.
you can check ip address, if You want accept request only from same server, place .htaccess in api directory or in virtualhost configuration directive, to allow only 127.0.0.1 or localhost. Configuration is based on what webserver You have.