Monday, August 10, 2015

Implementing HSTS

Everyone know the what HSTS (HTTP Strict Transport Policy) does- It instructs the browsers to load a website over HTTPS no matter what. You cannot load a website on the http. When you hit a website, eg,, the server returns ‘Strict-Transport-Security’ Header that tells that now onwards the website must be loaded over https.
We know the issue related to redirecting a site from http to https, the 302/ 301 redirects the site to its secure scheme by loading the when user hits . The issue here is the response from the first request which loads on http can be modified and contents can be replaced with some phishing ones. Still a large no. of websites do this redirection, one classic example is American Express. When you try to access first time , it redirects you to :

The website first loads as http and then makes a 301 redirect and loads again over https. The below pic will make it clearer:

Now let’s examine the following website (Facebook). Try accessing and it loads on . But there’s a difference here, instead of making 301/ 302 redirect the Facebook site makes a 307 redirect which is an internal redirect:

The 307 instructs that the browser is not going to make the first request itself on http, instead it will make the first request over https. The browser has refused to make any connection on insecure protocol http. Let’s examine the response:

You can see the HSTS header in the response:

All the sites which need to be loaded over https by default must be submitted to site. This site is maintained by chrome and has a list of domains which needs to be loaded over https by default. That means, when the browser is shipped, your site will be a part of the list where https is by default.

Tuesday, July 7, 2015

Bluetooth security modes and supported versions

Security Mode
Versions supported
No Security. Device operates in promiscuous mode allowing any other Bluetooth device to connect it
v2.0 and earlier devices support it.

v2.1 and later devices support for backward compatibility. 
Service level enforced security. Security measures are established after the channel is established. Supports Authentication, Authorization and Encryption.
v2.0 and earlier devices support it.

v2.1 and later supports for backward compatibility .
Link level enforced security. Security measures are established before the channel is established. Supports authentication and encryption.
v2.0 and earlier devices support it.

but v2.1 and later devices support for backward compatibility. 
It is a service level enforced security mode in which security procedures are initiated after link setup. Uses SSP (Secure Sample Pairing)
Mandatory for communication between v2.1 and later BR/EDR devices.

Backward compatible with any of the other three Security Modes.

Thursday, June 11, 2015

Difference between Cross-site scripting and Cross-frame scripting

Often mistaken and confused with each other- Cross site scripting (XSS) and Cross frame scripting (XFS) Both seems to be very similar to each other, but they are not. Both are pole apart. One deals with malicious Javascript injection, other one is related to framing of a particular page under another page. The later one is more of a phising attack.
XSS: Injection issue. Forced malicious javascript code execution in browser.

XFS: Phishing-like attack. Where a legitimate looking page is iframed inside a malicious website.


XSS: Input validation, Output encoding

XFS: Frame-busting code, so that the page can't be framed inside other websites.

Tuesday, May 5, 2015

One more attack on SSL

After Heartbleed, POODLE, one more in this series:

Wednesday, April 8, 2015

Agent based cloud scanning

As a part of security assessment of cloud based apps/ infrastructure we always face a challenge in scanning the servers in the cloud. Few of them are:
  • Obtaining/ managing credentials always an headache
  • Not ideal for cloud solutions
  • Requires target machines to be always online
The limitations of the scanners:
  • Traditional infrastructure scanners  such as Nessus are of not much use
  • Sometimes the scanners does not report  vulnerabilities correctly due to many issues such as machines frequently go down while scan is in process, some firewall issues etc
We need a solution which is rather than we scanning the target servers, it resides on the server and keep doing the scanning and sends the report back to the organization periodically. And here comes the concept of 'Agent based clod scanning'. 
The benefits are:
  • Rather than targeting the remote servers in the traditional approach, the agents installed on the servers keep on doing the scans and sends the periodic reports
  • Can run offline and syncs when becomes online
  • It helps reducing the network congestion
  • Enumerates Bluetooth, USB devices and mounted shares
  • Detects malwares and suspicious processes
Nessus recently launched such tool called, Nessus Agents which fulfills above conditions. 

Tuesday, March 10, 2015

Is Biometric authentication in reverse mode in Cloud a good bet?

Among many authentication modes for accessing resources over cloud, such as traditional authentication such as credentials, or muti-factor authentication, such as hardware tokens; the biggest issue is that they can be stolen, or mimicked. The traditional solutions available in market are mimicable and not fool proof, the hardware tokens, passwords etc. are easy to compromise. Also, the traditional approach towards the authentication process- first authentication via user credentials then use of any other mode of authentication such as hardware token- increases the attack surface.

How about reversing the above approach- first people who can prove who they are (Biometric) only can access the Login page. This will decrease the risk significantly as the login page will be available to a very few set of people rather than whole bunch.

So the steps are:
Biometric authentication- adding ‘what- you- are- factor’
Raises the security bar to the highest level
Challenging the traditional way of implementing multi-factor authentication:
1. First biometric authentication
2. Followed by, any traditional mode of authentication- passwords, tokens etc.
It reduces the probability of attack

Wednesday, February 4, 2015

Application security and PCI-DSS

So, how does PCI-DSS affects our web application security testing or what to make sure the application is compliant with PCI, while doing the security testing.

Here are few requirements which needs to be taken case while testing a web application which handles financial data such as credit card information. As the PCI guidelines itself maintains that the application must be tested on regular basis in "Requirement 11: Regularly test security systems and processes."

But what should really we look for? The requirement 11 is tied back to other requirements Requirement 6.:

11.2.1 Perform quarterly internal vulnerability scans and rescans as needed, until all “high-risk” vulnerabilities (as identified in Requirement 6.1) are resolved. Scans must be performed by qualified personnel.

11.2.3 Perform internal and external scans, and rescans as needed, after any significant change. Scans must be performed by qualified personnel.

11.3 Implement a methodology for penetration testing that includes the following:

      11.3.1 Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).

       11.3.2 Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).

Now let's check Requirement 6.1 says:

6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.

6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

6.3 Develop internal and external software applications (including web-based administrative access to applications) securely, as follows.

And what to test for:

6.5 Address common coding vulnerabilities in software-development processes as follows:

6.5.1 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.

6.5.2 Buffer overflows

6.5.3 Insecure cryptographic storage

6.5.4 Insecure communications

6.5.5 Improper error handling

6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process

6.5.7 Cross-site scripting (XSS)

6.5.8 Improper access control

6.5.9 Cross-site request forgery (CSRF)

6.5.10 Broken authentication and session management

Basically we need to test the web applucation for OWASP Top 10 vulnerabilities and addtionally we need to scan the servers and infrastructure for possible open ports, patches missing any other misconfigurations.

So basically, focus on Requirement section 6 while doing the testing.