I have enabled SSL and I am doing a jQuery AJAX post request and sending some fields to the server.
When I look at the AJAX post request through firebug under the post parameters I see all the fields in clear text.
So this means I can see the passwords in clear text. Is this normal? I am also looking at it with fiddler and it does not even log this AJAX request(so its like the request was never made).
So is it just because firebug is installed in the browser and can capture it or what?
ssl enables security when the data moves from browser to web sever. Firebug is a browser plugin, it knows everything in the DOM tree. I think it makes sense for firebug display the input fields and form data.
Yes, you can see the field data because FireBug is capturing the requests inside Firefox before they're encrypted. If you inspect the actual network traffic with a protocol analyzer like Wireshark you'll see that it's encrypted.
Off the top of my head I would think that Firebug is showing you exactly what is being sent. Otherwise it would mean that it is somehow decode encoded information.
If you really want to confirm this, use a tool which can capture the web traffic outside of the browser. Tcpdump for example.
"So this means I can see the passwords in clear text. Is this normal?"
Yup. The data resides on your browser, that is - the user agent, and is captured before it is communicated to the server. Any encryption operation is vulnerable to sniffing at the point at which the value enters the closed system. That's why if your machine is compromised (say, by malware) very little will help.
Related
I have a web application written in PHP. The templating engine is SMARTY. My question is very simple, yet the answer should not be that easy, because I searched the hell out of it to no avail.
When I telnet to port 80 and run the following command:
GET /some_directory_on_my_server/?""><SCRIPT>alert(123)</SCRIPT>
The servers responds back with an html page. When I save this HTML page and open it in a browser I see alert(123) on top of the page, which means that the site is vulnerable to Cross-Site Scripting (XSS).
My question is how can I access the actual url entered by the user in order to sanitize it? When it comes to user input sanitization for forms or database queries, the scenario seems to be much easier, because you actually have a variable on hand to manipulate, but in the case of actual url entered by the user in a browser, how can I get hold of the url itself to sanitize it?
For your information, I have already read all modules which provide library functions for XSS Prevention, but none gives me an example on how to deal with actual url XSS Attack. By the way, my magic_quote_gpc in my php configuration is already turned off. What should I do now? Any thoughts?
We are reviewing the design of a system. And need to verify what we think may be a security issue.
In this system some sensitive information is sent in the query string. Question is:
Can the query string parameters be read as the request goes over the internet, even if the request is sent over https?
Can the query string parameters be read be read from the browsing history on the client machines?
When you use HTTPS, the SSL/TLS connection is established before any HTTP traffic is sent, thus the whole request (including the URL and its parameters) will be encrypted and won't be readable. The only thing that's possibly visible by a third party is the server certificate (so they could see the host name, but that's it).
The browser's history isn't protected in any way by HTTPS as such, although some browsers may have some "safe browsing" options which would delete some HTTPS URLs automatically perhaps. This one ultimately really depends on the browser and its configuration.
This is certainly a security issue if sensitive details are being passed in get request.
Sensitive data will not only get cached in the user's browser but also in any proxy on d way and plus in webserver logs
Yes for the first. Not sure about the second - depends on the browser, I guess - but I suspect, Yes, here as well.
I have a quite simple task:
i need to download file from a web page. In browser, it is done by pressing submit button. Just simple button, press it and you see the pop-up window asking where to save file and so on. Data is sent to server via post method.
I tried POST'ing with curl like: curl -d "foo=bar&....." [URL]
but this request returns the page itself, not the file. And I am quite confused about how to get the file, since I dont know it's adress on server and the only way to get it is to press this freaking button.
Please help
If you use unix-like os system you can use wireshark by simple apply filter "http", or some other software, e.g. tcpdump.
if you under ms windows, fiddler2 is very good tools.
first,
use this kind tools get the accurate information about the tracfic.
then analyze the http request, especially the rquest cookies header.
finally, struct your own request by curl.
the foo=bar&.....
is only the content of the request. you may also attention the header of the request.
or your can post your url, so that other peoplle can help you analyze the stuff.
Use Wireshark or a browser plugin that captures the http request sent on submit, then use curl or, for example, PHP's file_get_contents() to emulate the request.
I have SSL on my website....when the user logs in from a http page the form action is sent to https page, would this still secure the posted data?
Or would it be better to have the form and the page it is posted to both SSL?
Thanks
It is absolutely necessary for both the page with the form AND the page being submitted to to be HTTPS. Unless the page with the form has HTTPS, you can make no guarantees about where that form is submitting to. It may not actually submit to an HTTPS page (are you expecting your visitors to view the source) or something may have inserted some malicious javascript to redirect the form to somewhere else. However if the form is also HTTPS then you know that it hasn't been tampered with.
Security is more than just ticking a box saying "I have encryption", it's a whole process.
But here's the important part (and why the only correct answer to this question is "both FROM and TO must be HTTPS) that most people forget: HTTPS (and SSL/TLS in general) isn't just encryption, that is only a part of it. It's about TRUST:
You know where your data is being submitted to. This includes not just the server hostname but also the identity of who that hostname represents
You know that nothing has been tampered with along the way
Without HTTPS on the FROM page, #2 above can't be guaranteed (the FROM page could be tampered with) which means that #1 can't be guaranteed. After all, if your form were somehow tampered with, how do you know what that form will do with your data in the end?
Yes the transmission of the form data is still secure. You can use a network sniffer (Fiddler, NetMon, ...) to validate this. But for the user experience you should still put your login form on an SSL site. That way they see the "lock" icon in their browser. Also, there's no guarantee that the form hasn't been tampered with if you don't use SSL (as Adam said).
You need to have the form page with SSL to be secure.
I have a login screen which I'm serving over SSL. The user fills in their login/password, this gets POSTed to the server. At this point I want to jump out of SSL, so I redirect them back to the same page with no SSL.
This causes the browser to show a warning dialog "You are about to be redirected to a connection that is not secure". How can I avoid this? I've been plenty of sites like yahoo mail, and gmail that give you an SSL page for login, then send you to a non-SSL page after this.
Secondary question: what's the purpose of this dialog? It's trying to warn me about some nefarous purpose - but what's so bad about redirecting someone to a non-SSL page? I don't get a warning when I'm on an SSL page and click a non-SSL link. What's different about redirecting someone?
I'm doing this in ASP.NET 2.0 - but I figure this is a generic web-dev question.
UPDATE SUMMARY: It seems the popular answer is "DON'T AVOID IT". I can understand that a user should get a message when security it being removed. But I don't get a dialog when I follow a link and security is removed, so at the very least I'd say this is inconsistent.
The dialog / browser versions. I actually don't see the dialog in IE7/FF3 (maybe I've clicked a checkbox preventing it). More importantly the client DOES see it in IE6 - with no checkbox to remove it (yes, I know IE6 is old and crap).
Firefox2: FF2 http://img521.imageshack.us/img521/8455/sslwarning.jpg
IE6:
The alternative: make the entire site SSL, never redirect the user out of SSL. I could handle that. But I've got a semi-technical client who has some fairly good points:
"SSL is going to cause an increase in traffic / processing power". I don't really buy this, and I don't think his site is every going to require more than one box to serve it.
"Yahoo does it. Yahoo is a big technical company. Are you smarter than Yahoo?"
I'm going to try sway the client over to an entirely SSL site. I'll argue Yahoo's approach made sense in 1996, or for a site that is MUCH more popular. Some official links explaining why this dialog happens would help (i.e Jakob Nielsen level of authenticity).
I've hit this same problem a while back. So I had a look inside fiddler to see how yahoo mail does it. Here's the step I saw (and used on my site):
User fills in SSL encrypted form, and POSTs to the server. Server authenticates, and spits out some script to redirect the client
<script language="JavaScript">
<!--
window.location.replace("~~ non-SSL URL ~~");
// -->
</script>
I figure the client side code is there to avoid this dialog.
"How can I avoid this?"
You shouldn't!
Although you could try that with JavaScript. This might work on some browsers and fail on others.
"What's the purpose of this dialog?"
It warns because switching between SSL and non-SSL on websites is usually unexpected by the user. A warning about the "non-SSL to SSL" is not emitted since it increases security and privacy. However, when security is suddenly decreased, the user should notice that quickly, in order to avoid a false feeling of security. In fact, redirecting to a non-SSL site is sometimes used in XSS/MITM attacks.
"SSL is going to cause an increase in traffic / processing power"
This is nonsense. It might be true for sites full of big, static content. However, for normal dynamic web applications, encryption is very cheap compared to business logic, database access, etc.
There is an urban legend saying that SSL-content is not chached by browsers. See "Will web browsers cache content over https" for more information.
"Yahoo does it. Yahoo is a big technical company. Are you smarter than Yahoo?"
Some rhetoric counter-questions:
Are you a big technical company like Yahoo?
Did being a big technical company prevent Microsoft from producing crappy software?
Do you have to support crappy old (SSL-broken) browsers, as Yahoo has to?
The attack this is preventing against is a man-in-the-middle SSL session strip. The message is there with good cause.
As for the purpose: It's to make you aware that your connection won't be SSL encrypted anymore. You may have seen before that the connection is encrypted and may think that it still is, so this warning says "Just to be clear, whatever data you send from here on will be plaintext".
As for how to suppress it: AFAIK you can't, it's a browser thing, what would be the point of the message otherwise? Even though there are workarounds like client-side redirects, I don't think you should try to work around client "problems" like this. If the browser chooses to be verbose, let it. There's a "Don't show this again" checkbox on the dialog after all If the user wishes to suppress this message he can easily do so, and maybe he actually likes to see it.
Also, IMHO, if the browser was worth its salt it would still pop up this warning, even if you employed client-side redirect tricks.
Use SSL for the whole page in the first place!
There's nothing wrong with SSL. You should provide user privacy everywhere, not only on login. It makes sense an the whole site. So simply redirect all non-SSL pages to SSL pages and keep everything SSL.
Just point your client to the latest attacks against mixed mode content (lookup CookieMonster on fscked.org) and proxy attacks (against sites available both in http and https, lookup Pretty-Bad-Proxy). He might reconsider.
It is much easier to get security right if you only deal with one protocol without mixing the two. SSL adds a bit of overhead, but it is nothing compared to the cost of a breach.
Gmail, yahoo, etc. use SSL for an encrypted iframe, which authenticates, but there's none of the in-page redirection you're talking about. The whole page isn't encrypted for these login systems.
read:
http://support.microsoft.com/kb/883740
which says that this is fixed in a hotfix or with a changed registry setting. However, not all the IE6 cpu's we use have this problem, nor do their registry settings correspond to what this article says they should. Also some that give the msg are XPsp3 and IE6 sp3.
We have an https log in screen that uses code to log into 15 other (http) domains and some of our IE6 users have to click 'Yes' 15 times. This is inacceptable to them.
No, we cannot control what browser all our users use. Some are not compatible with upgrade to IE7.
We are looking for some config attribute for each user to adjust that will suppress this msg. We've identically configed a 'bad' browser with settings that match one that does not give the msg. Internet and Intranet Security and Advanced settings and Proxies (none).Also Network connections. No joy so far.
Any ideas?