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.
Related
I'm analysing a project that uses Spring Security and AngularJS. I know there is a CSRF vulnerability within a specifc form, but I'm unable to get my head around it.
The server sets a CSFR Token as a cookie (not HTTP only, not Secure) for each session. It remains the same for each session. On form submission, AnagularJS takes this cookie and appends it to a custom HTTP header, as shown below.
My understanding is that this is the best method of protecting a site, double submit. With the assumtion that it's already XSS secure, it will not be possible for another site to set a custom header on a HTTP request?
I've searched many forums and many say this is the best method of using a CSRF token, even better than putting within a hidden field in the form.
I'd like ask if anyone knows why this method isn't secure and if it is vulnerable to CSRF.
Many thanks!
P.S - I should add the CSRF token appears to be a randomly generated value, not linked to the session. If I use burpsuite to edit both the header and cookie, to any value, the server will still accept it.
I'm attempting to locate the CSRF vulnerability and then I can work on repairing it.
I am trying to redirect my user from a html page to a jsp page which has been deployed on tomcat/webapps using .war file.
While doing so, I am also sending the session information of the user as an hidden parameter via POST method.
With the help of burpsuite tool(security testing tool) one can easily manipulate the cookie and change the username of the user logged in. How will I be able to block such kind of cookie manipulation?
You cannot control/prevent what the browser/client is sending, so do not consider the data received as fact/true. Your application shouldn't just look at the username and say "oh, it's the admin user, I show the whole admin area".
To prevent tampering the data originated from the server or at least detect changes, you use encryption or digital signatures. With encrypted data, it is not possible to change the data. You don't know how to decrypt the data and encrypt the changed data correctly since you don't have the encryption key to do so. With signed data you can still read the data but the signature makes sure that you can detect, if the data has been changed.
In your case, you can use a JWT instead of just the username. The JWT contains a digital signature which is used to check if the data has been changed. Your "testing team" can change the data but your server can see immediately that it has been changed and reject the received (changed) information.
I have a site, http://foo.com. I have another site, https://bar.com. If I submit a form from non-secured foo.com to secured bar.com, is the transaction encrypted?
Example:
http://foo.com/form.html
<form action="https://bar.com/process.php" method="post">
...inputs, validation, and form happiness...
</form>
My use case is forms emailed to users that may contain sensitive information that need to be submitted to our site (which has SSL). The form would be an attachment that would be opened from their desktop for example and filled out, then submitted to our server. Is there a way to encrypt that communication?
I found two potentially relevant questions, which give conflicting answers:
Secure Cross Domain Form Submission
[yes, it is secure, but] Not inherently secure. The SSL on the host is not relevant, the SSL on the third party server is. However you must set the post to "https://..." rather than just "http://", it isn't enough for it to be a "secure server" you have to invoke it securely.
Securing Forms submitting to a diffrent domain
One simple way is to use HTTPS and but thats as long as both can be HTTPS. They must also both have SSL certificates.
Since the form is going to be posted to a secure server https://bar.com/process.php, data will be encrypted along with the request. On the other hand it wouldnt be secure even if the form had been hosted on a secured https://bar.com/form.html but had been posted to a non secure http://foo.com/process.html
Here's excerpt from the article "Sending form data" on Mozilla Developer Network
Note: It's possible to specify a URL that uses the HTTPS (secure HTTP)
protocol. When you do this, the data is encrypted along with the rest
of the request, even if the form itself is hosted on an insecure page
accessed using HTTP. On the other hand, if the form is hosted on
secure page but you specify an insecure HTTP URL with the action
attribute, all browsers display a security warning to the user each
time they try to send data because the data will not be encrypted.
ref: Sending form data: MDN Article
Yes, it is encrypted. No, it is not secure.
The reason being is that the user has no assurance that the form is secure. A Man-In-The-Middle could have intercepted the response from http://foo.com and changed the form to:
<form action="https://evil.example.com/process.php" method="post">
...inputs, validation, and form happiness...
</form>
and the user would be none the wiser that they were sending insecure data until after the horse had bolted. evil.example.com may redirect back to https://bar.com to decrease their chances of detection.
Bottom line: Always place sensitive forms on HTTPS pages. This gives assurance to the user that their submitted data will be safe in transit.
In my site, users can only modify their personal information only once a day. Script-side, I determine if they are allowed to (i.e. check with the database if it's been 24 hours since the last modification) and whether or not to display the form.
My question is, could a malicious user manage to submit information if there's no form? In other words, if there is no FORM element no data should be submitted by the user's browser, right?
What I'm afraid of is that if someone manages to send the data, the script would still process it and change the personal information when it shouldn't.
Of course - this would be a kind of replay attack. So long as your resource endpoint will handle a malicious POST request, regardless of the content of the preceding GET then you're vulnerable.
Remember: never trust the client. Provided that you do authentication and authorization checks before handling a POST request then you'll be fine.
Yes, a malicious user can still send data even without the form, if he knows the url of the page which accepts the data and their corresponding attributes it expects. He can then easily create a form with that info and submit the data.
So you basically need to validate the data at the server-side.
YES
For example someone could use curl.
curl -d profile=value http://www.yoursite.com/profile
You could prevent such attacks with a CSRF token you send along with your form.
See this article for more background http://shiflett.org/articles/cross-site-request-forgeries.
I want to set up a project page on GitHub, so that it acts as a live site.
The site would require an API sid & token (both just long strings of text) that, in a self-hosted environment, the user would just add to the config file.
If I host this through GitHub project pages, users will supply their sid/token through a form. The page with the form will need to be served over SSL so that the sid/token aren't transferred as cleartext. The problem is that GitHub project pages don't allow SSL.
So, if I can find another secure way to take input through a form aside from using SSL, then I can host this whole thing a hosted service through GitHub project pages.
The project would be open source, so I don't expect any sort of encoding/hashing scheme to work, since the methods would be public.
The sid/token are being used in curl calls to an API which is sent over SSL. Perhaps there's a way to direct the form input directly to that SSL URL instead of having it go through the non-SSL GitHub project page...
Any ideas?
You can just give the action attribute of the form the HTTPS URL of the target script, if that's possible.
You could also use some kind of Challenge-Response encryption/hashing scheme using Javascript. The algorithm for that would be something like this:
Server generates unique, random token, saves it and sends it to the client along with the form HTML.
On the client side, Javascript intercepts the form submission and hashes the sensitive form data with the server-generated token as a salt.
Server can now check whether the hash is equal to its own calculated hash value
HOWEVER
A man-in-the-middle attacker with the ability to modify traffic (for example through ARP poisening, DHCP or DNS spoofing) could always strip all your client-side protection mechanisms from the served HTML. Have a look at SSLStrip for a tool to rewrite HTTPS URLs to unsecure HTTP URLs on the fly. The challenge-response could be defeated something like this:
Save token sent by the server, remove the Javascript from the HTML form.
As the form submission is not intercepted now, we get the raw input data.
Hash the data using the same algorithm that the Javascript would have performed.
Thank you for all the fish.
You see, an intercepting attacker can probably defeat any defense mechanism you try to make up.