Secure Development Lifecycle for Open Source Usage

Preface How do we adjust the SDL (Security Development Lifecycle) process for the growing use of open source in internal/external systems we develop and maintain? This is a question I hear a lot lately from our customers in some recent SDL projects we (AppSec Labs) carried out for our customers. After we did some research, […]

Password Autocomplete vulnerability and a workaround solution

Until recently, it was trivial for developers to disable the “save you password” feature implemented by all major browsers. However, in the last years, browser vendors have begun to actively discourage and prevent applications from disabling this feature. Their case is that the safest practice for users is to use a password manager, instead of having their passwords lying around on digital or physical support, where they can be exposed or stolen. Since it’s a client-side issue, they claim that the option should be given to users (and not to the developers) to disable this feature by configuring the browser itself.

Although this may be partly true, it does not take into account highly sensitive applications, which might be used on a shared computer, and which do not want to rely on the browser being properly configured (with autocomplete disabled). If this is your case, you should keep on reading.

It is now a real challenge to find a workaround that will work across all major browsers. So we came up with the following trick which detects the user’s browser version and acts accordingly:

Read more

Case study – Open Redirect

Most of us are familiar with the ‘Open Redirect’ vulnerability; an OWASP top 10 vulnerability that takes advantage of a situation in which the application receives a parameter from the client and uses it to build the URL location to which the user is redirected, without performing sufficient validation on the received input.

Typically, attackers can exploit vulnerable applications in order to perform phishing attacks, redirecting the victims to phishing sites that look exactly (or partially) like the vulnerable application. The victims tend to believe they are still in the original website, and provide their credentials in order to perform the required login. Unfortunately, these credentials are sent directly to the attacker.

A Classic Open Redirect Scenario

The following image demonstrates a vulnerable website (victim-site.com), which is vulnerable to the common open redirect scenario; a login page that will redirect the user to the page specified in the ‘returnURL’ parameter after successful login (the rectangle outlines the URL of the index page):

Read more

headers-security-headers

Improve your Web App’s security with HTTP Headers

Over recent years, new security standards have been set by the W3C, and implemented by browser vendors. The idea was to create a set of HTTP headers that developers could use in order to add a browser-based layer of security for their web applications.

Indeed, many security problems can (or should) be remediated on the client side (e.g. Same Origin Policy), and by improving the security of the platforms it was clear that the overall security level of web applications would increase, with little regard to the actual server-side implementation.

Let’s present a quick overview of these HTTP headers:

X-XSS-Protection

Description: Enables a Cross-Site Scripting (XSS) filter in the browser that blocks the malicious reflected XSS code.

Setting: X-XSS-Protection: 1; mode=block

Supported Browsers: IE 8+, Chrome, Safari (WebKit).

Additional Information: https://blogs.msdn.microsoft.com/ie/2008/07/02/ie8-security-part-iv-the-xss-filter/

X-Content-Type-Options

Read more