Monday, September 8, 2014

Login page behavior

I came across a strange behavior in one web application.
In one tab logged into the web application and in another tab I accessed the login page again. I was thrown out of the first logged in tab too.
Is it desired behavior? I guess the session IDs are shared across tabs and and once logged in one tab can access any page in other tabs.
Let me know if you have any answer.

Tuesday, August 5, 2014

Login page insecure design

Sometimes we come across with the login pages which are not initially served over https, rather it's redirected to https. 
The second scenario is wherein, the login page is served over http but the login section in that page is loaded in a  frame, where the credentials are submitted over https.

Both can be considered as an insecure design as both are susceptible to MITM attacks.
Because the login form was loaded over HTTP, it was open to modification by a malicious party. Every link/URL present on that page (not just the form action) needs to be served over HTTPS. This will prevent Man-in-the- Middle attacks on the login form.
An attacker who exploited this design vulnerability would be able to utilize the information to
escalate their method of attack, possibly leading to impersonation of a legitimate user, the
theft of proprietary data, or execution of actions.

The best defense comes from user's perspective, where a user may directly access the website over https or he may book mark it.

For the second scenario, the whole page needs to be served over https, not just login section. 


The page loaded on http can be modified and inserted with JavaScript or phishing links:

Wednesday, July 9, 2014

Risk of self signed certficates

Risks of Using Self Signed Certificate for Authenticity:

Anyone can create a self-signed certificate, and anyone can put whatever meta-data that they want into it. So, two self-signed certificates can look and behave identically, one can't visually distinguish between a legitimate and a forged certificate. It means, anyone can create similar cab file & digitally sign using self-signed legitimate or forged certificates, send to our customers. The customer will not able to differentiate between fake and genuine one.

Risks of Using Self Signed Certificate for Integrity:

User creates a file for distribution using his own self signed certificate and sends to receiver. Here an attacker too creates a his own self-signed certificate with the same name. Attacker does a MITM, captures User’s data, modifies it, removes the signature (in case of dlls, exes just remove from PE header), re-signs with his own self-signed certificate and forwards it to the receiver. This way the data can be tampered and there’s no way for the receiver to detect it as he will be able to decrypt and match the hashes using Attacker’s sent public key.


Wednesday, June 4, 2014

A New Kind of Security: Bionic Labs Wants to Call Your Friends to Verify You’re You

Stumbled upon a good post about a new kind of authentication mechanism, presented by Bionic Labs in Recode conference:

See yourself:

Thursday, May 8, 2014

Wednesday, April 9, 2014

HeartBleed vulnerability

Was about to write about this, meanwhile found this post very useful. Why to reinvent the wheel?
So here you go:
Written by Rahul Sasi.

Tuesday, March 11, 2014

Password reset feature in single user, isolated environment applications

I came across one application while doing security assessment and found that they were using default admin account.And that too the admin account was having credentials as admin:admin. Catastrophic, isn't it?
I raised this issue before completing the assessment with the developers. They had their usual excuse- this was introduced to help user reset their passwords through the web application and since the web application was supposed to be used by singles user. It was essentially a single user environment. The web application was running locally on their individual laptops and the laptop was being plugged on the LAN just for few moments to reset some device readings.

Now the risk was:
Even a momentarily the laptop was connected to local network, the default admin account's presence was known to every other user. If they change the password using the default account then?
Though this was single user environment and only very few users were supposed to use the application on their individual laptops, we can't ignore the risk.

But then there's was no mechanism to reset the password as there was no email accounts associated or nor admin present to reset the password. It was very simple web application to just record and generate reports about some sensors' health.

So after brainstorming, we proposed the following solution in this kind of single user and isolated environment without compromising with usability:
Implementing a feature of local password reset in this single user environment. Develop a CLI (Command Line Interface)/ console based utility which changes the password locally on the machine, rather than providing this facility as web interface as this might be accessed remotely. The utility directly resets the password into database from command line. This approach provides both security and usability in current single user