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.
Related
The Question
Is there a way to detect wether a visitor trusts the SSL connection/certificate? I really could not find anything on the web or on stackoverflow. I think it's a pretty uncommon question.
A Use-Case
I'm using a certificate from StartSSL. It works fine for most common and modern browsers. But on my Windows Phone using IE I get a warning. That's because the root certificate is not known to IE on Windows Phone by default.
The solution is easy: just download the certificate - two clicks/taps. I would like to provide a tiny guide to the common visitor on how to do this. However, only visitors with problems should get the message.
Visitors who connect to your site via HTTPS simply won't get to your site if they don't trust your certificate. Once an exception has been added, there's no way for you to determine whether or not it's generally trusted or an exception.
Perhaps you could try to build a list of user-agents and make a guess as to what their default CAs should be, so as to be able to display an additional message in this case. It's not a perfect rule (since you can never full control what the client trusts, it's the user/admin's responsibility), and has the disadvantages of user-agent specific content; in particular, it's not necessarily reliable, you won't have a complete database, and users who've already added the exception or imported the certificate permanently would see this additional message (unless you use something like a cookie to remember).
If your initial page is over plain HTTP, you might be able to try an XHR request to your HTTPS site and report whether it worked at all. (You might need to take into account the Same Origin Policy.)
I am not sure whether there is a foolproof way to auto-detect this condition. You may have to rely on a workaround.
Detect whether the request is from a phone by inspecting user-agent in the header, check whether it's the first time they are accessing your site (absence of your site's cookie etc.) and if they are first time user, redirect response to (HTTP) page with instructions to install the certificate. You can provide a check box on that page for users to supress that redirect behavior in furture. If they want it to be supressed, set a cookie, or store their preference on server (if there is authentication).
I'm writing an Apple iOS app that login to a account and fetching some balance. It use a plain html link for the login:
https://www.myaccount.com/login.jsp?username=myusername&password=mypassword
The username and password is dynamically loaded to the login link at runtime.
I've sniffed the traffic using Wireshark and I couldn't find the username or password in any of the packages being sent. I guess the SSL(?) thing of "https" have encrypted the query.
I'm I right? Is this a safe way? Any other thoughts? How should I handle the password in the app to avoid security issues? Is it cached? Do I need to encrypt it if I want the app to remember my password?
Although technically safe as Sjoerd pointed out, this is just great for social engineering. In the internet cafe: "Dammit, that's a cool article. Can you email me the URL real quick?"
You won't believe how many people fall for this kind of stuff.
Another drawback is that Browsers tend to cache URLs, so again very unsafe in situations where multiple people have access to the same machine.
A much better way is to use HTTP Basic Authentication or at least HTTP POSTing the data.
This is secure in the sense that it can not be sniffed, since the request is sent over an encrypted HTTPS channel. However, it does show up in the address bar of the browser and possibly in the log files of the server.
The safer way is to POST the username and password to the JSP page, so that they do not show up in the URL.
I have a test plan that runs fine under http, and the Cookie Manager is correctly keeping my sessions in place. It is also capable of talking to the same server when switched to ssl, and even thinks everything is working correctly because it gets a 200 response with our custom message about not being logged in.
All I need to do to reproduce the behavior is switch from http to https. The test is still able to talk to the server, but I can see in the "View Results in Table" log that cookies has a JSESSIONID under http, and is empty under https. And each request under ssl is answered with a Set-Cookie for JSESSIONID.
Interesting scenario. Does the Jmeter log file offer any clues?
Could it be that Jmeter needs a copy of the certificate to properly store the SSL cookie? The console would display a handshake problem, which can be resolved by adding the certificate into the key store:
http://www.java-samples.com/showtutorial.php?tutorialid=210
You might be able to do some further debug by writing out the cookie value to a variable and logging its value:
Received Cookies can be stored as JMeter thread variables (versions of JMeter after 2.3.2 no longer do this by default). To save cookies as variables, define the property "CookieManager.save.cookies=true". Also, cookies names are prefixed with "COOKIE_" before they are stored (this avoids accidental corruption of local variables) To revert to the original behaviour, define the property "CookieManager.name.prefix= " (one or more spaces). If enabled, the value of a cookie with the name TEST can be referred to as ${COOKIE_TEST}.
Source: http://jmeter.apache.org/usermanual/component_reference.html#HTTP_Cookie_Manager
Edit: Somebody asked how my specific problem was solved. It turned out not to have anything to do with ssl specifically, but that other unrelated headers changed very slightly in their format, so the regex we were using to match on them started failing. So I'd start there with looking at your headers and comparing the difference between when you post http vs https
My service might use referer information to tell from what web site a request is done, and I would like to make sure there is no way to fake the referer information.
Referer can be easily spoofed.Using a referrer is very unreliable as a method of verification.
There exists a firefox plugin called refspoof to do that very easily.
Even command line tools like wget have options to do that: --referer=url
It is possible. There's nothing you can do to prevent browsers from faking that data.
There are many ways to fake any information sent by the client. The most basic rule of accepting information from a client is: don't trust the client.
Ever.
Browsers can fake, among many others, their User-Agent string and referrer (the proper spelling, the PHP function is about the most prolifically perpetuated typo going).
It's easily spoofed, so I wouldn't rely on it for anything important.
The client is free to send you what ever data it wants. You should -never- trust what the browser sends.
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.