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.
Related
Our single page app embeds videos from Youtube for the end-users consumption. Everything works great if the user does have access to the Youtube domain and to the content of that domain's pages.
We however frequently run into users whose access to Youtube is blocked by a web filter box on their network, such as https://us.smoothwall.com/web-filtering/ . The challenge here is that the filter doesn't actually kill the request, it simply returns another page instead with a HTTP status 200. The page usually says something along the lines of "hey, sorry, this content is blocked".
One option is to try to fetch https://www.youtube.com/favicon.ico to prove that the domain is reachable. The issue is that these filters usually involve a custom SSL certificate to allow them to inspect the HTTP content (see: https://us.smoothwall.com/ssl-filtering-white-paper/), so I can't rely TLS catching the content being swapped for me with the incorrect certificate, and I will instead receive a perfectly valid favicon.ico file, except from a different site. There's also the whole CORS issue of issuing an XHR from our domain against youtube.com's domain, which means if I want to get that favicon.ico I have to do it JSONP-style. However even by using a plain old <img> I can't test the contents of the image because of CORS, see Get image data in JavaScript? , so I'm stuck with that approach.
Are there any proven and reliable ways of dealing with this situation and testing browser-level reachability towards a specific domain?
Cheers.
In general, web proxies that want to play nicely typically annotate the HTTP conversation with additional response headers that can be detected.
So one approach to building a man-in-the-middle detector may be to inspect those response headers and compare the results from when behind the MITM, and when not.
Many public websites will display the headers for a arbitrary request; redbot is one.
So perhaps you could ask the party whose content is being modified to visit a url like: youtube favicon via redbot.
Once you gather enough samples, you could heuristically build a detector.
Also, some CDNs (eg, Akamai) will allow customers to visit a URL from remote proxy locations in their network. That might give better coverage, although they are unlikely to be behind a blocking firewall.
The following is quoted from RFC6455 - WebSocket protocol.
Servers that are not intended to process input from any web page but
only for certain sites SHOULD verify the |Origin| field is an origin
they expect. If the origin indicated is unacceptable to the server,
then it SHOULD respond to the WebSocket handshake with a reply
containing HTTP 403 Forbidden status code.
The |Origin| header field protects from the attack cases when the
untrusted party is typically the author of a JavaScript application
that is executing in the context of the trusted client. The client
itself can contact the server and, via the mechanism of the |Origin|
header field, determine whether to extend those communication
privileges to the JavaScript application. The intent is not to prevent
non-browsers from establishing connections but rather to ensure that
trusted browsers under the control of potentially malicious JavaScript
cannot fake a WebSocket handshake.
I just cannot be sure about what the 2nd paragraph means, especially the italic part. Could anyone explain it a bit? Or maybe an example.
My understanding so far is like this:
If server CAN be sure that requests DO come from Web pages, the ORIGIN header can be used to prevent access from un-welcomed Web pages.
If server CANNOT be sure that requests come from Web pages, the ORIGIN header is merely advisory.
Your understanding seem to be correct, but..
I would rephrase it - you can be sure, that javascript client will send proper origin header. You don't know what will be sent by other clients (and whether the value is correct or not).
This should prevent other pages to connect to "your" web socket endpoints (which is a big deal, imagine injected javascript somewhere on jsfiddle or some frequently visited page), but if you need to make sure that no other client will be able to connect to it, you'll need to introduce some other security measures.
I believe this is meant only as prevention of browser based "data stealing" or "DDoSing", nothing else; you can still do that by using some other client.
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
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.
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.