Don't know why people do not practice AJAX implementation for authentication systems. Is it insecure? If yes how? I have developed an authentication system that submit user information through an iframe, but the problem is it opens a new window in IE6.
Don't know why people do not practice AJAX implementation for authentication systems.
Usually because the differences between "logged in" and "not logged in" are quite significant, so the cost of reloading the entire page is relatively insignificant.
Is it insecure?
Not intrinsically. Security comes from SSL, not from forms or JavaScript.
There is no difference, they are both sent exactly the same way.
It's all just http.
It makes a difference if you are sending authentication over ssl, how cookies or authentication headers are encrypted and so on.
What doesn't makes a difference is if it's an AJAX request or an IFrame or a Form post and so on.
Related
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.
User open the index page presented with basic browser authentication, but he doesn't respond and provides username/password.
In this scenario, I want to kill that http request, is there any way of doing it. I remember we can set a timeout cookie but not sure.
Would window.stop(); work? There's a way to cancel an ajax request using <object>.abort(); but I don't think that will help you in your situation.
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'm contemplating making a project, but I'm wondering if cross-site request forgery would make it impossible to secure.
Basically, I want to have a web service that generates a form using the usual tricks(JSON-P and iframes) on another domain's page. So WebService.example.com generates a form's HTML, and it's shown to the user on User.example.com
This form, I assume will have to use the injected iframe trick to submit the form from javascript. Because anyone would be able to just get the same data from WebService.example.com, how can I ensure that it's actually only coming from User.example.com? Preferably, without having to have any server-side code running on User.example.com.
Note, I'll be using ASP.Net for the WebService, but I'd like it explained in a language/framework agnostic manner
This is pretty hard to do without using server side scripts on both domains.
If you change your architecture and just use Cross-Domain Messaging (host the form etc in the top domain, use iframe for communication) then you could use the XDM to verify that it is indeed the intended domain you are talking to.
If you only target HTML5-capable browsers then use postMessage, if you want broader support, and things like RPC etc then use easyXDM, which abstracts all of the hassle with cross-domain messaging.
Actually, you can host your form in either document, you just need to use the XDM-communication in order to do a successful 'handshake', verifying the origin.
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.