One of customers have reported that they can see the password being transferred as clear text, they probably tried tool like a fiddler to capture the HTTP request/response. So my question is is it possible using fiddler or any other tool is it possible for someone to monitor the http traffic on that local computer at the moment the user entered the password and clicked to login ?
If the user is accessing the website without using SSL (i.e. by going to "http://" instead of "https://"), then it is possible to see all of the traffic between the website and the browser, and not only on the local computer but also on the network that the computer is connected to.
If the user is accessing the website via HTTPS, Fiddler is able to act as a proxy and decrypt the traffic between the browser and the server by using a special SSL certificate (thanks to #user18044 for clarification in the comments below).
In your case Fiddler is NOT accessing browser memory directly to get to the password in clear text.
Related
I'm running a Node.js server for my college final year project. It's running on my local machine and I'm accessing it via the machine's private IP address. The application needs to record a short snippet of audio and send it back to the server, which will then send back a result based on the content of the audio file. Because the browser needs access to the microphone, it has to be HTTPS, even though I am not dealing with any sensitive information or even opening it to the internet. I just need to show it working at a demonstration, which I can do on a local network.
After hours of trial and error I managed to modify my current application to use HTTPS using a self signed certificate as described here. I can now access the web page over HTTPS (albeit with a huge red "This page is not actually secure" warning that I have to accept first) and chrome will grant me access to the microphone. However, when I click the button that sends a post request with the audio, chrome gives me either
POST https://192.168.178.30:8443/notes net::ERR_CERT_AUTHORITY_INVALID
or
POST https://192.168.178.30:8443/notes net::ERR_CERT_COMMON_NAME_INVALID
I have installed the cert as a trusted root certificate as outlined here.
I set the common name on the cert as the IP address (192.168.178.30) but chrome still won't accept it, and I don't have a domain name (it's running locally).
So my question is: how do I either make a trustworthy OpenSLL certificate, or force chrome to ignore such errors. I have a day to get this working along with other aspects of the application so I ned a quick fix. This is for the purpose of a demonstration, it is not going live to the internet.
I have a trivial question about web architecture. When I build a web service/application, I want to make it only work perfectly on https protocol.
Firstly I analyzed the google's methodology by network session of chrome developer tools. In there I found it, when a http request is sended to the google, that the request redirected to https of same origin.
I thought it is a respectable way. But I find it has a potential risk. When an authorized user using the google, he have a session. And after, he want to deep another site (e.g. Yahoo). And he will come back to the google by inserting the address 'google.com' directly in browser's address box. In this situation if the user didn't shut off the google session, in the redirect process, the unencrypted session token will be sended to google because the redirect process be proceeded on http protocol. So this user will be exposed MITM(man in the middle) attack.
So I hesitate to use google methodology. Anyone have a idea?
Set the secure flag on the session cookie. Then it won't ever be sent over HTTP.
I've got a requirement to detect if a webpage is being served on the internet or intranet, i.e. assuming a url of https://accessibleanyway.com, is the phone connected to the work wifi or to something else like their home wifi or the phone network?
What different ways are there to do this?
(1) Use WebRTC to get the local ip address. Not widely supported
(2) Try to access a local web page using jsonp/cors/iframe
The problem with 2 is that the webpage is https and the local resource is likely to be http which you can't do in IE afaik. If I make the local resource https then it's via a self cert which means installing CAs on the phones (can you buy certificates for the intranet anymore?)
Any suggestions?
The problem with (2) was that the same page was trying to use http and https, and even with an iframe you get issues.
What you could do instead is start on a http loading page, use an iframe to access a local resource which you can only access if you are on the intranet, jsonp will work fine for this. Once that's worked or failed, redirect to your start page with some token in the querystring to indicate that you are on the intranet or not
NB jumping from http to https would probably have some security issues if you are on the same website (authentication cookies being initially visible), but I would have thought it would be fine if you are going to a different one
Obviously there'll be some security needed around the token as otherwise the user could just generate their own but that's a different matter which depends on individual setups. It would obviously have to be generated by a server call, otherwise someone could just read the client code.
NB I think the IP address approach is never going to work as you have no way of knowing what a companies intranet setup looks like until you go there, so it's not a generic answer
If I open Fiddler and log into 50 different websites from my browser... in a perfect world, would Fiddler ever be able to show me my password in plain text?
If it does, is that a security problem with the website?
If not, how can you tell if a website is sending data unencrypted? Wireshark?
Did you enable HTTPS decryption in Fiddler? If so, then Fiddler is doing something that no web based attacker can easily do, and seeing your password shouldn't worry you.
If you didn't enable HTTPS decryption, or you see your password in a session whose protocol is HTTP, then the website is not sending your password securely, and anyone able to sniff your HTTP traffic could see your password.
I was using google SSL search (https:www.google.com) with the expectation that my search would be private. However, my search for 'toasters' produced this query:
https://encrypted.google.com/search?hl=en&source=hp&q=toasters&aq=f
As you can see, my employer can still log this and see what the search was. How can I make sure that when someone searches on my site using SSL (using custom google search) their search terms isn't made visible.
The URL is sent over SSL. Of course a user can see the URL in their own browser, but it isn't visible as it transits the network. Your employer can't log it unless they are the other end of the SSL connection. If your employer creates a CA certificate and installs it in your browser, they could use a proxy to spoof Google host names, but otherwise, the traffic is secure.
HTTPS protects the entire HTTP exchange, including the URL, so the only thing someone intercepting network traffic will be able to determine is that there was communication between the browser and your site (or Google in this case). Even without the innards, that information can be useful.
Unless you have full administrative control over the systems making the queries, you should assume that anything transpiring on them can be intercepted or logged. Browsers typically store history and cache pages in files on the local disk which can be read by administrators. You also can't verify that the browser itself hasn't been recompiled with code to log sites that were visited, even in "private" mode.
Presumably your employer provides you with a PC, the software on it, the LAN connection to its own corporate network, the internet proxy and corporate firewall, maybe DNS servers, etc etc.
So you are exposed to traffic sniffing and tracing at many different levels. Even if you browse to a url over SSL TLS, you have to assume that the contents of your http session can be recorded. Do you always check that the cert in your browser is from google and not your employer's proxy? Do you know what software sits between your browser and your network card, etc.
However, if you had complete control over the client, then you could be sure that no-one external to your https conversation with google would be able to see the url you are requesting.
Google still knows what you're up to, but that's a private matter between your search engine and your conscience ;)
to add to what #erickson said, read this. SSL will protect the data between the connected parties. If you need to hide that link from the boss then disable the browser caching of the sites visited, i.e. disable or delete the history data.