Posts

Showing posts with the label Security

Heartbleed bug in OpenSSL

There was a serious vulnerability reported in the OpenSSL library that can let the attacker to dump memory contents from the server. Thus the attacker can perform offline analysis of the memory contents and identify sensitive information like private key of the server, key material for SSL sessions, decrypted data that is in memory, etc. This affects any server that uses OpenSSL to implement HTTPS. I thought I will share some material in one place that will be helpful for people to understand the problem better. Description of the problem can be found here . A simple Python script to test your servers can be found here  or you can use this site . NVD entry for this issue can be found here . How some of the companies are responding: Heroku , AWS , Lastpass . Hope that helps.

Two cookie attributes you MUST be aware to secure your web app

There are two attributes of cookies that every web developer must be aware of to secure your web application. These two attributes doesn't save your application from all attacks, but at least they reduce the vulnerability to a great extent. These two attributes are: HttpOnly Secure The first attribute HttpOnly says that the cookie is intended to be passed only as a part of HTTP communication. Hence it must not be available to the application (like JavaScripts running in the browser). So once you load a page, if you type "javascript:alert(document.cookie)" in the URL bar, you will not those cookies that have the HttpOnly flag set. The second attribute Secure tells that the cookie should be sent as a part of the request if and only if the communication happens over a HTTPS channel. Typically login requests are sent over HTTPS channels. (If you are using a web app that is using HTTP for login page, its time you stop using it!). Typically, as a part of the login response...

Gmail over HTTPS

I had always been wondering what is the problem with these email providers, that they don't let me view my emails over HTTPS. One of the main reasons I could think of was the increased load on the web servers where the HTTP connection terminates. They will have to spend extra CPU cycles to encrypt/decrypt the incoming and outgoing data. Similar load will be incurred on the user's machine as well. But Google provides mail over HTTPS. And that is seriously a good news. To access your email over HTTPS, instead of typing www.gmail.com, type "https://mail.google.com". Oh BTW, it is only the traffic comes from Google mail server to your desktop that is encrypted. Still the traffic between the mail servers go in unencrypted form. For e.g., if you are sending an email from your Google mail account to some account in Yahoo!, the mail will be sent in unencrypted form from Google server to the Yahoo! mail server. Added on 07/29/2008: A friend of mine working in Google told me ev...

Serious security issue with IRCTC website

The login form of the IRCTC web site is being submitted over HTTP in plain text. This is a very serious issue since both your user ID and password could be sniffed by someone. One thing that I observed was that they have a HTTPS server running and this server is capable of receiving login requests. I think it was a bug in the code that the developer gave the URL as HTTP instead of HTTPS. How to overcome the issue? This is not a clean approach but works fine. You can copy and paste the URL "https://www.irctc.co.in/cgi-bin/bv60.dll/irctc/services/login.do?userName=XXX&password=YYY" in your browser. Replace the XXX with your user ID and YYY with your password. I tried to send a feedback about this to the site admin or someone in charge. Pathetic ... I could not find any link/email address in that website to do this. Hopefully someone from IRCTC will read this blog and fix the issue.