Thursday, February 23, 2017

HTTP GET vs. POST in HTML Forms - Security Considerations Explained with a Sample

This blog post explains security considerations when using HTTP GET as the request method compared to HTTP POST. Here for accessing the form’s data posted to the server, I use a PHP file for demonstration, but you can use any other technology (JSP, ASP.NET etc.).

Here I have a simple login page written in HTML.

This is the sample source code of login.html file.

      <title>login page</title>

   <h1>Welcome to My Site !</h1>

   <form action="validateuser.php" method="get">
      Username : <input type="text" id="username" name="username"/>
      Password : <input type="password" id="password" name="password"/>
      <input type="submit" value="login"/>      

When you click the login button, the browser will redirect you to the web page/URL defined in the action of the HTML form. In this sample, I have a PHP file named validateuser.php and both the login page and this file are deployed in apache web server.

In the HTML form of the login page, the method is defined as get.
Therefore, in the validateuser.php file also we need to access the form data using $_GET[‘parameter name’].

This is the sample source code of validateuser.php file.


   $username = $_GET["username"];
   $password = $_GET["password"];

   //perform authentication


Now enter some value for username and password and click the login button.

Browser will redirect to the validateuser.php page. However, since the HTML form’s method was defined as get, all the form’s data (here username and password) will be added as query parameters in the URL.

The risk here is, the URLs users request from the server (here Apache web server) are printed in the access logs of the server. Therefore, anybody having access to the filesystem of the web server would see the query parameters in the URLs printed in the log file. (By default in linux operating system, if you install apache server, the logs are added to the /var/logs/apache2/access.log file)

Therefore it is not recommended to use HTTP GET method when you need to send sensitive data in the request.

Now let’s do a small modification to the login page and set the method to post.

      <title>login page</title>

   <h1>Welcome to My Site !</h1>

   <form action="validateuser.php" method="post">
      Username : <input type="text" id="username" name="username"/>
      Password : <input type="password" id="password" name="password"/>
      <input type="submit" value="login"/>      

In the validateuser.php file I retrieve the HTML form’s data using $_POST[“parameter name”].

Here’s the source code of validateuser.php file.


   $username = $_POST["username"];
   $password = $_POST["password"];

   //perform authentication


Now if you fill the form in the login page and click the button, data (username and password) will not be added to the URL as query parameters, but will be included in the body of the request.

If you check the web server logs, you can’t see the form data in the request.

Therefore, if your HTML web form sends sensitive information when the form is submitted, it is recommended to use HTTP POST method so that the data will not be sent to the server in the URL as query parameters.

Tharindu Edirisinghe (a.k.a thariyarox)
Independent Security Researcher

Saturday, February 18, 2017

Secure Software Development with 3rd Party Dependencies and Continuous Vulnerability Management

When developing enterprise class software applications, 3rd party libraries have to be used whenever necessary. It can be either to reduce development costs, meet deadlines or simply because of the the existing libraries already provide the functionality that you are looking for. Even though the software developed in-house of your organization are developed following best practices adhering to the security standards, you cannot be certain that your external dependencies meet the same standard. If the security of the dependencies are not evaluated, they may even introduce serious vulnerabilities to the systems you develop. Thus it has been identified by OWASP as one of the top 10 vulnerabilities [1]. In this article, I will discuss how to manage security of your project dependencies and how to develop a company policy for using 3rd party libraries. I will also discuss and demonstrate how this can be automated as a process in the software development life cycle.

Before moving ahead with the topic, we need to be familiar with the technical jargon. Go through the following content to get some idea on them.

What is a 3rd Party Library ?

A reusable software component developed to be either freely distributed or sold by an entity other than the original vendor of the development platform.

The third-party software component market thrives because many programmers believe that component-oriented development improves the efficiency and the quality of developing custom applications. Common third-party software includes macros, bots, and software/scripts to be run as add-ons for popular developing software. [2]

Using 3rd Party Components in Software Development

If you have developed software using any 3rd party library (here I have considered C# and Java as an example), following should be familiar to you where you have injected your external dependencies to your project in the IDE.
3rd party dependencies of a C# project in Microsoft Visual Studio
3rd party dependencies of a Maven based Java project in IntelliJ IDEA

Direct 3rd Party Dependencies

The external software components (developed by some other organization/s) that your project depends on are called as direct 3rd party dependencies. In the following example, the project com.tharindue.calc-1.0 (developed by myself) depends on several other libraries which are not developed by me, but by some other organizations.

Direct 3rd Party Dependencies with Known Vulnerabilities

The external software components (developed by some other organization/s) with known vulnerabilities that your project depends on are direct 3rd party dependencies. In this example, the project that I work on depends on commons-httpclient-3.1 component which has several known vulnerabilities [3].

Transitive 3rd Party Dependencies

The software components that your external dependencies depend on are called as transitive 3rd party dependencies. The project I work on, depends on component and component which are the direct 3rd party dependencies. These libraries have their own dependencies as shown below. Since my project indirectly depend on those libraries, they are called as transitive 3rd party dependencies.

Transitive 3rd Party Dependencies with Known Vulnerabilities

The software components with known vulnerabilities that your external dependencies depend on belong to this category. Here my project has the transitive 3rd party dependency of mysql-connector-5.1.6 library whereas it has several known vulnerabilities.

What is a Known Vulnerability

When we use 3rd party libraries which are publicly available to be used (or even proprietary), we may find a weakness in that library in terms of security that can also be exploited. In such case we can report the issue to the development organization of that component so that they would fix it and release as a higher version of the same component. Then they will publicly announce (Through a CWE or a CVE discussed later) the issue they fixed so that the developers of other projects that are using the vulnerable component get to know the issue and apply safety precautions to their systems.

Common Weakness Enumeration (CWE)

A formal list or dictionary of common software weaknesses that can occur in software's architecture, design, code or implementation that can lead to exploitable security vulnerabilities. CWE was created to serve as a common language for describing software security weaknesses; serve as a standard measuring stick for software security tools targeting these weaknesses; and to provide a common baseline standard for weakness identification, mitigation, and prevention efforts. [4]

Common Vulnerabilities and Exposures (CVE)

CVE is a list of information security vulnerabilities and exposures that aims to provide common names for publicly known cyber security issues. The goal of CVE is to make it easier to share data across separate vulnerability capabilities (tools, repositories, and services) with this "common enumeration." [5]

CVE Example

ID : CVE-2015-5262
Overview :
http/conn/ssl/ in Apache HttpComponents HttpClient before 4.3.6 ignores the http.socket.timeout configuration setting during an SSL handshake, which allows remote attackers to cause a denial of service (HTTPS call hang) via unspecified vectors.
Severity: Medium
CVSS Score: 4.3


Software weaknesses are errors that can lead to software vulnerabilities. A software vulnerability, such as those enumerated on the Common Vulnerabilities and Exposures (CVE®) List, is a mistake in software that can be directly used by a hacker to gain access to a system or network [6].

Common Vulnerability Scoring System (CVSS)

CVSS provides a way to capture the principal characteristics of a vulnerability, and produce a numerical score reflecting its severity, as well as a textual representation of that score. The numerical score can then be translated into a qualitative representation (such as low, medium, high, and critical) to help organizations properly assess and prioritize their vulnerability management processes [7].


National Vulnerability Database (NVD)

NVD is the U.S. government repository of standards based vulnerability management data represented using the Security Content Automation Protocol (SCAP). This data enables automation of vulnerability management, security measurement, and compliance. NVD includes databases of security checklists, security related software flaws, misconfigurations, product names, and impact metrics.

Using 3rd Party Dependencies Securely - The Big Picture

All the 3rd party dependencies (including 3rd party transitive dependencies) should be checked in NVD for detecting known security vulnerabilities.

When developing software, we need to use external dependencies to achieve the required functionality. Before using a 3rd party software component, it is recommended to search in the National Vulnerability Database and verify that there are no known vulnerabilities existing in those 3rd party components. If there are known vulnerabilities, we have to check the possibility of using alternatives or mitigate the vulnerability in the component before using it.

We can manually check NVD to find out if the external libraries we use have known vulnerabilities. However, when the project size grows where we have to use many external libraries, we cannot do this manually. For that, we can use tools and given below are some examples.

Veracode : Software Composition Analysis (SCA)

This is a web based tool (not free !) where you can upload your software project and it will analyze the dependencies and give you a vulnerability analysis report.

Source Clear (SRC:CLR)

This provides tools for analyzing known vulnerabilities in the external dependencies you use. The core functionality is available in the free version of this software.

OWASP Dependency Check
Dependency-Check is free and it is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Currently Java, .NET, Ruby, Node.js, and Python projects are supported; additionally, limited support for C/C++ projects is available for projects using CMake or autoconf. This tool can be part of a solution to the OWASP Top 10 2013 A9 - Using Components with Known Vulnerabilities.

Following are some very good resources to know more about OWASP Dependency Check tool.

Continuous Vulnerability Management in a Corporate Environment

When developing enterprise level software in an organization, the developers cannot just use any 3rd party dependency that does provides the required functionality. They should request approval from engineering management to use any 3rd party software component. Normally the engineering management would check for the license compatibility in this approval process. However it is important to make sure that the 3rd party dependency has no known security risks for using it. In order to achieve this, they can search the National Vulnerability Database to check if known issues are there. If no known security risks are associated with that, the engineering management can approve using the dependency. This happens in the initial phase of using 3rd party dependencies.

During the development phase, the developers themselves can check if the 3rd party dependencies have any known vulnerabilities reported. They can use IDE plugins that automatically detect the project dependencies, query the NVD and give the vulnerability analysis report.

During the testing phase, the quality assurance team also can perform a vulnerability analysis and certify that the software product does not use external dependencies with known security vulnerabilities.

Assume that a particular 3rd party software component does not have any known security vulnerabilities reported at the moment. Then we pack it in our software and now our customers are using the software. Let’s say after 2 months of the software release, a serious security vulnerability is reported against that 3rd party component which makes our software also vulnerable to an attack. How to handle a scenario like this ? For this, in the build process of the software development organization, we can configure a timely build job (using a build server like Jenkins, we can schedule a weekly/monthly build for the source code of the released product). We can integrate plugins to Jenkins to query NVD and detect vulnerabilities of the software. In this case, we can retrieve a vulnerability analysis report and that would contain the reported vulnerability. So we can create a patch and release to customers to make our software safer to use. You can read more on this in [8].

Above we talked about handling security of 3rd party software components in a continuous manner. We can call it as continuous vulnerability management.

Getting Rid of Vulnerable Dependencies

Upgrade direct 3rd party dependencies to a higher version. (For example, if you use Apache httpclient 3.1, it has several known vulnerabilities. However if you use the latest version like 4.5.2, it does not have reported vulnerabilities)

For transitive dependencies, check if the directly dependent component has a higher version that depends on a safer version of the transitive dependency.
Contact the developers of the component and get the issue fixed.

Challenges : Handling False Positives

Even though the vulnerability analysis tools report that there are vulnerabilities in a 3rd party dependency, there can be cases where those are not applicable to your product because of the way you have used that software component.


Challenges : Handling False Negatives

Even though the vulnerability analysis tools report that your external dependencies are safe to use, still there can be unknown vulnerabilities.



Identify the external dependencies of your projects
Identify the vulnerabilities in the dependency software components.
Analyze the impact
Remove false positives
Prioritize the vulnerabilities based on the severity
Get rid of vulnerabilities (upgrade versions, use alternatives)
Provide patches to your products

Notes :

This is the summary of the teck-talk I did on Jun 15th, 2016 at the Colombo Security Meetup on the topic ‘Secure Software Development with 3rd Party Dependencies’.

The event is listed in OWASP official website  


Tharindu Edirisinghe (a.k.a thariyarox)
Independent Security Researcher