I have a HTTP page with a form. If I set the action to a HTTPS page, is the request secure? Does the browser process all the data before it sends it to the net? Or should I use HTTPS for my entire site?
Yes, it'll be secure if the location your form is posting to is HTTPS.
Users, however, may freak out that there's no lock icon in their browser on the page with the form. You may be better off from a usability standpoint having both pages be HTTPS.
No. Troy Hunt identifies a simple man-in-the-middle attack that shows that posting from HTTP to HTTPS is by no means secure. With the proliferation of free WiFi this attack would be very simple to execute.
http://www.troyhunt.com/2013/05/your-login-form-posts-to-https-but-you.html
Yes. As long as the request that needs to be secure is https, you're good.
That being said, many key sites, including gmail, have stopped bothering carving off small sections of their site to be https and just made their whole site https. It's easier and safer, and you lose little in the way of performance.
Dont do it!
Consider a MITM attack where an attacker sitting on the wire somewhere between the server and client modifies the login form before it reaches the client. The login form now includes a keylogger or points the POST action to a phishing page instead of the authentic server. There is no warning or UI cue for the end-user, so they go ahead and submit the form.
Consider a MITM attack that involves the attacker deploying a "free Wifi" at a coffee shop (via a smartphone hotspot or whatever). When unsuspecting people use this "free Wifi" to login with an HTTP form, even though it does a POST to HTTPS, the attacker can see the user's plaintext credentials by analyzing their hotspot network traffic.
References:
TLS and SSL in the real world
SSL Strip
Your login form posts to HTTPS, but you blew it when you loaded it over HTTP
Is it secure to submit from a HTTP form to HTTPS?
The actual data transfer from your form to the server is encrypted when posting over HTTPS. If that is what you mean by secure, then yes, it is secure.
I think what you are getting at in your question is, what about client-side stuff reading the form prior to post. That is certainly possible, HTTPS or not.
On another note though, you should probably use HTTPS for the actual form. Some browsers warn users as their posts are redirected over the HTTP/HTTPS boundary. Plus, I don't think your users will be happy filling out a form where there is no secure icon showing.
If you set action to HTTPS this will indeed be secure. Before anything can happen over HTTPS a handshake has to occur, and the browser sending the data will have to do this when the action occurs.
Related
Is it ok to pass passwords like this or should the method be POST or does it not matter?
xmlhttp.open("GET","pas123",true);
xmlhttp.send();
Additional info: I'm building this using a local virtual web server so I don't think I'll have https until I put upfront some money on a real web server :-)
EDIT: According to Gumo's link encodeURIComponent should be used. Should I do xmlhttp.send(encodeURIComponent(password)) or would this cause errors in the password matching?
Post them via HTTPS than you don't need to matter about that ;)
But note that you need that the page which sends that data must be accessed with https too due the same origin policy.
About your money limentation you can use self signed certificates or you can use a certificate from https://startssl.com/ where you can get certificates for free.
All HTTP requests are sent as text, so the particulars of whether it's a GET or POST or PUT... don't really matter. What matters for security in transmission is that you send it via SSL (and handle it safely on the other end, of course).
You can use a self-signed cert until something better is made available. It will be a special hell later if you don't design with https in mind now :)
It shouldn't matter, the main reason for not using GET on conventional web forms is the fact that the details are visible in the address bar, which isn't an issue when using AJAX.
All HTTP requests (GET/POST/ect) are sent in plain text so could be obtained using network tracing software (e.g. Wireshark) to protect against this you will need to use HTTPS
Is it correct to switch from HTTPS to HTTP (say by clicking a click which has full path in the href - with HTTP). Appreciate if someone let know what are the implications in such cases.
Thanks.
This actually can be a security risk, it depends on your situation.
If you create a session in that HTTPS part, and then visit a HTTP page of the same domain, the session cookie will be sent along with the unsecure HTTP request (plaintext). This makes your site vulnerable to session hijacking, an attacker can use this session id and has the same privileges as the logged in user has.
In PHP you can prevent this behaviour, calling the session_set_cookie_params() function, setting the $secure parameter to true. This tells the browser, to send the cookie to HTTPS pages only.
The browser will load a page from a non SSL source. No real implications as far as security is concerned.
Switching from HTTPS to HTTP is entirely correct if that is what the link is intended to do.
Implications include losing the encrypted communication link between client and server that HTTPS provides.
ssl encryption for the http (s) is used to protect transmitted information. For example, use https on the lognin page. After logging on, you can redirect to http.
So switching https and http is quite all right.
I'm not sure I understand what types of vulnerabilities this causes.
When I need to access data from an API I have to use ajax to request a PHP file on my own server, and that PHP file accesses the API. What makes this more secure than simply allowing me to hit the API directly with ajax?
For that matter, it looks like using JSONP http://en.wikipedia.org/wiki/JSONP you can do everything that cross-domain ajax would let you do.
Could someone enlighten me?
I think you're misunderstanding the problem that the same-origin policy is trying to solve.
Imagine that I'm logged into Gmail, and that Gmail has a JSON resource, http://mail.google.com/information-about-current-user.js, with information about the logged-in user. This resource is presumably intended to be used by the Gmail user interface, but, if not for the same-origin policy, any site that I visited, and that suspected that I might be a Gmail user, could run an AJAX request to get that resource as me, and retrieve information about me, without Gmail being able to do very much about it.
So the same-origin policy is not to protect your PHP page from the third-party site; and it's not to protect someone visiting your PHP page from the third-party site; rather, it's to protect someone visiting your PHP page, and any third-party sites to which they have special access, from your PHP page. (The "special access" can be because of cookies, or HTTP AUTH, or an IP address whitelist, or simply being on the right network — perhaps someone works at the NSA and is visiting your site, that doesn't mean you should be able to trigger a data-dump from an NSA internal page.)
JSONP circumvents this in a safe way, by introducing a different limitation: it only works if the resource is JSONP. So if Gmail wants a given JSON resource to be usable by third parties, it can support JSONP for that resource, but if it only wants that resource to be usable by its own user interface, it can support only plain JSON.
Many web services are not built to resist XSRF, so if a web-site can programmatically load user data via a request that carries cross-domain cookies just by virtue of the user having visited the site, anyone with the ability to run javascript can steal user data.
CORS is a planned secure alternative to XHR that solves the problem by not carrying credentials by default. The CORS spec explains the problem:
User agents commonly apply same-origin restrictions to network requests. These restrictions prevent a client-side Web application running from one origin from obtaining data retrieved from another origin, and also limit unsafe HTTP requests that can be automatically launched toward destinations that differ from the running application's origin.
In user agents that follow this pattern, network requests typically use ambient authentication and session management information, including HTTP authentication and cookie information.
EDIT:
The problem with just making XHR work cross-domain is that many web services expose ambient authority. Normally that authority is only available to code from the same origin.
This means that a user that trusts a web-site is trusting all the code from that website with their private data. The user trusts the server they send the data to, and any code loaded by pages served by that server. When the people behind a website and the libraries it loads are trustworthy, the user's trust is well-placed.
If XHR worked cross-origin, and carried cookies, that ambient authority would be available to code to anyone that can serve code to the user. The trust decisions that the user previously made may no longer be well-placed.
CORS doesn't inherit these problems because existing services don't expose ambient authority to CORS.
The pattern of JS->Server(PHP)->API makes it possible and not only best, but essential practice to sanity-check what you get while it passes through the server. In addition to that, things like poisened local resolvers (aka DNS Worms) etc. are much less likely on a server, than on some random client.
As for JSONP: This is not a walking stick, but a crutch. IMHO it could be seen as an exploit against a misfeature of the HTML/JS combo, that can't be removed without breaking existing code. Others might think different of this.
While JSONP allows you to unreflectedly execute code from somwhere in the bad wide world, nobody forces you to do so. Sane implementations of JSONP allways use some sort of hashing etc to verify, that the provider of that code is trustwirthy. Again others might think different.
With cross site scripting you would then have a web page that would be able to pull data from anywhere and then be able to run in the same context as your other data on the page and in theory have access to the cookie and other security information that you would not want access to be given too. Cross site scripting would be very insecure in this respect since you would be able to go to any page and if allowed the script on that page could just load data from anywhere and then start executing bad code hence the reason that it is not allowed.
JSONP on the otherhand allows you to get data in JSON format because you provide the necessary callback that the data is passed into hence it gives you the measure of control in that the data will not be executed by the browser unless the callback function does and exec or tries to execute it. The data will be in a JSON format that you can then do whatever you wish with, however it will not be executed hence it is safer and hence the reason it is allowed.
The original XHR was never designed to allow cross-origin requests. The reason was a tangible security vulnerability that is primarily known by CSRF attacks.
In this attack scenario, a third party site can force a victim’s user agent to send forged but valid and legitimate requests to the origin site. From the origin server perspective, such a forged request is not indiscernible from other requests by that user which were initiated by the origin server’s web pages. The reason for that is because it’s actually the user agent that sends these requests and it would also automatically include any credentials such as cookies, HTTP authentication, and even client-side SSL certificates.
Now such requests can be easily forged: Starting with simple GET requests by using <img src="…"> through to POST requests by using forms and submitting them automatically. This works as long as it’s predictable how to forge such valid requests.
But this is not the main reason to forbid cross-origin requests for XHR. Because, as shown above, there are ways to forge requests even without XHR and even without JavaScript. No, the main reason that XHR did not allow cross-origin requests is because it would be the JavaScript in the web page of the third party the response would be sent to. So it would not just be possible to send cross-origin requests but also to receive the response that can contain sensitive information that would then be accessible by the JavaScript.
That’s why the original XHR specification did not allow cross-origin requests. But as technology advances, there were reasonable requests for supporting cross-origin requests. That’s why the original XHR specification was extended to XHR level 2 (XHR and XHR level 2 are now merged) where the main extension is to support cross-origin requests under particular requirements that are specified as CORS. Now the server has the ability to check the origin of a request and is also able to restrict the set of allowed origins as well as the set of allowed HTTP methods and header fields.
Now to JSONP: To get the JSON response of a request in JavaScript and be able to process it, it would either need to be a same-origin request or, in case of a cross-origin request, your server and the user agent would need to support CORS (of which the latter is only supported by modern browsers). But to be able to work with any browser, JSONP was invented that is simply a valid JavaScript function call with the JSON as a parameter that can be loaded as an external JavaScript via <script> that, similar to <img>, is not restricted to same-origin requests. But as well as any other request, a JSONP request is also vulnerable to CSRF.
So to conclude it from the security point of view:
XHR is required to make requests for JSON resources to get their responses in JavaScript
XHR2/CORS is required to make cross-origin requests for JSON resources to get their responses in JavaScript
JSONP is a workaround to circumvent cross-origin requests with XHR
But also:
Forging requests is laughable easy, although forging valid and legitimate requests is harder (but often quite easy as well)
CSRF attacks are a not be underestimated threat, so learn how to protect against CSRF
How secure would this setup be ?
Unsecure page 'http://www.site.com' makes an XMLHttpRequest with POST
to url 'https://www.site.com/dosomething.asp'
The page dosomething.asp has header 'Access-Control-Allow-Origin: http://www.site.com' set
and returns some user related data that needs to be secure.
No errors, all goes well.
How secure is the actual POST request ?
How secure is the responseText from this request ?
The most significant issue I can see is that your unsecure page is not secure (ok, obvious). If someone were to attempt a man-in-the-middle attack on that unsecure page, they could edit the functionality of the page (using JavaScript injection, etc.) to intercept the content being sent to and received from the secure URL. You are best off to use both pages in secure mode (SSL/TLS).
As soon as you introduce a non-SSL component to your application, you have lost all the benefits of SSL. You are only as secure as the weakest part. This is why browsers report mixed SSL/non-SSL content as a security alert to the user.
Wireshark is a program that monitors network packets traveling across a network. It's free and popular. The definitive way to answer this question would be get Wireshark, take a day to learn it, and apply it.
The filter to see traffic from the source site would be:
(ip.src == [ip address of source]) && (ip.dst == [ip address of target])
Swap ip.src and ip.dst to see what's coming back. You could actually combine both in one filter expression actually.
This would work provided that you're on the network through which the packets are traveling.
One final item: Here's a description of PKI (https/SSL/TLS): http://www.mitre.org/news/the_edge/february_01/steve.html
I Wiresharked a sort of similar situation, and verified I was sending and receiving TLS (https) traffic. But it wasn't this situation exactly so I don't want to speculate.
Lets consider next scenario: assume I have a web app, and authentication of users is performed through a modal dialog window (lets say, that when a user clicks login button, ajax request is sent and depending on the callback I either close the window or display an error), and I use only HTTP protocol. Why is it considered to be not secure way to do things?
Also, please make sure that a modal dialog window is taken into account, because this is vital info. There may be some data displayed underneath the dialog window and can be accessible if modality is broken.
The question includes both:
How can you break an app security by
utilizing ajax call?
Is Ajax HTTP less secure than a
regular form HTTP?
Whoever told you - he is wrong. The ajax through post is not less secure than post with regular forms. Just because it is the same thing.
Update 1 according to the last edit:
You cannot
No
Argument: the AJAX request is the same http request as any other (such as request sent by html form). Absolutely the same. So by definition it cannot be less or more secure.
I don't know how to explain more and what to say else: ajax is a http request. the same request as your browser does when you open SO page or when you post the SO question form.
I can rephrase your question to something like "Why A is less secure than A". Answer to it: A is not less secure than A, because A is A :-S
Any sensitive data should be channeled through HTTPS. GET data is sent in the querystring. POST data is sent in the HTTP Request header. Ajax can do both. BOTH are not secure. You need a channel level encryption to really secure it.
HTTP isn't secure for private data because the data is transmitted in plaintext. This can be intercepted anywhere between the client and server (eg. wifi.) Ajax over HTTPS would be much better.
I think the issue is that you are using http. No matter how you look at it it wont be secure. If you use https the ajax request will be just as secure as a html form.
Somy answer would be to use https and you will be all set.
I'm no security expert, but I think it might be more secure sending it over HTTPS. Just googling learns me that it can be done securely though:
http://www.indicthreads.com/1524/secure-ajax-based-user-authentication/
http://msdn.microsoft.com/en-us/magazine/cc793961.aspx (focused on ASP.NET)
etc.
Since browsers use the same network stack for HTTP and HTTPS, be it AJAX or not, there is no difference. All the headers, cookies, authentication, etc work exactly the same.