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.
Related
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 would like to know if it's possible to provide an email certificate (signed by a recognised CA) so the user clicking on the mailto link can send encrypted email to the owner of the cert ?
hello#gmail.com
Is there any way to do that using the mailto link or using some JS ? Given the mailto link is handled by a local email client, should be possible ?
If there is no direct way to do this, how to make it?
One option is a web form for message sending, served via HTTPS. The server-side handler of the form would compose an encrypted mail on the server and then send it via SMTP. This provides almost the same level of security as direct encryption (given that your server is secure). Unfortunately there's no other simple way to do what you want. Of course, you can put a link for your .cer file download and tell the user to download the .cer file and use it to compose an encrypted mail, but how would you deal with GMail users and mobile users? Web form is more flexible and easier to use for the sender.
You can look up what you according to the current specification can do with a mailto URL in RFC 2368. You'll see that it only refers to the construction of the mail text and headers, not their encoding or encryption. There may be extensions for some mail clients, but that's not something one should generally count on.
Furthermore, Web mail users generally will have problems with such links anyways. Thus, for a solution that has to be usable by anyone, a scheme counting on some client side program is not a good choice.
Thus, some Web form as mentioned by #Eugene accessable only via https would best serve your requirements.
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
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.
Is HTTPS as the (HTML) form's action enough for the form data to be SSL encrypted for submission?
Or does the page that hosts the form have to be HTTPS as well?
If the page the form is hosted on is not served over HTTPS, then it can be intercepted and modified en route. These modifications can include such things as changing the action of the form, or adding JavaScript to send the data to a third party before submitting the form as normal.
Submitting the form over HTTPS is not sufficient to protect the data. The form needs to be delivered that way too.
HTTPS on the form's action is sufficient to encrypt the form submission.
The page that hosts the form doesn't have to HTTPS, although it helps to give the users confidence that their data is secure.
The other benefit of securing the hosting page is that the form can't be spoofed or altered by a man-in-the-middle.
It is enough if all you want to do is wave the magical encryption fairy dust around. It's not enough if you want to actually be secure. Any man-in-the-middle attack could simply rewrite the form HTML to post to a malicious server.