Secure Development Lifecycle

Secure Coding Practices & Development

Veracode – Application Security Solution — February 27, 2017

Veracode – Application Security Solution

Week 11

We are nearing the end of the Blog series where we discussed the importance of Secure Software Development and a number of vulnerabilities that exist today. The task for any organization that wants to seriously consider the security of its applications is enormous. In this blog post we will take a look at one of the application security platforms that can help an organization achieve it’s security goals.

Veracode is an application security firm based out of Massachusetts. Found in 2006 it provides an automated cloud-based service for securing web, mobile and third-party enterprise applications. Veracode helps organizations eliminate vulnerabilities during the lowest cost point i.e. the development phase. With its powerful and automated solutions organizations can tightly integrate Veracode platform in the SDLC. Veracode takes a holistic approach to application security where the powerful cloud solution can perform multiple analysis technologies to identify threats and technologies. Some of the offerings include:

Binary Static Analysis (SAST)

Static Application Security Testing (SAST) refers to white box testing which is performed by analyzing the application data model and control paths. The model is searched for all possible paths that represent a possible threat such as XSS, SQL injection attack. The advantage of binary analysis is that the organization source code is never exposed since it scans the complied binaries. Also Veracode has the ability to scan 3rd party assembly files without a need for any source code.

Software Composition Analysis

Open source components are a blessing for most organizations where they can speed up the development by using and extending openly available source code. However just like any other code they’re prone for security vulnerabilities. Veracode Software Composition Analysis (SCA) helps an organization build an inventory of open source components to identify vulnerabilities, covering open source and commercial code.

Integration with Agile and DevOps

Integration is key when testing for security. Ideally as soon as the code is checked in and available for a build the security scan should get triggered. If the scan fails the build should be rejected. With the use of APIs Veracode is able to accomplish this by seamlessly integrating into development and DevOps workflows.

Dynamic Analysis (DAST)

Dynamic application security testing is commonly referred as black box testing where the web application is tested to find architectural weakness and vulnerabilities. The DAST analysis uses the same techniques as used by cyber criminals for example testing the input fields, query string parameters.



Flash Security — February 19, 2017

Flash Security

Week 10

Flash provides rich multimedia experience developed by Adobe in 1996. Since it’s inception it has been widely adopted for creating interactive web interfaces, games, videos and animations. With it’s wide spread adoption it has been frequently targeted by hackers and for the last few years it has been in the headlines for wrong reasons. Flash vulnerability is on the rise and there has been a lot of concern raised by the tech industry regarding it’s future and the steps adobe needs to take.

In the past couple years one might have heard multiple times that “Flash is Dead” only to find out no it’s not. Yes HTML 5 can accomplish a lot and more of what Flash can do but the reality is the organizations who built major application on Flash won’t simply go away any time soon. When iPhone was launched it took first steps to raise awareness regarding security concerns about the Flash plugin when it didn’t support Flash at all on the Safari browser. This was a hot topic at that time and numerous efforts were made to convince Apple to enable Flash support. Fast forward today the 4 main browsers i.e. Chrome, Firefox, Safari and Edge all disable Flash by default. However the main stream browsers are still leaving the option for the user to enable Flash plugin as needed.

Flash has a long history of critical security updates and patches, only to find more issues surface. The most common flash vulnerabilities include executable code, denial-of-service, overflow and Cross-Site Scripting. Due to the severity of the issues many technology experts have encouraged the users to disable Flash completely and look for alternatives. The site CVE explains flash vulnerabilities in detail. The below chart taken from CVE clearly shows the flash vulnerabilities are on the rise and it is well and alive today.


The last two years have been the worst for the Flash plugin and is really pointing out the the huge risk that a typical user is exposed to. My personal recommendation is to stay away from Flash completely and I hope in near future the browsers drop Flash support completely. This is the only way I can see organizations looking for other technologies and port their Flash applications as soon as possible.


JavaScript Security — February 11, 2017

JavaScript Security

Week 9

 JavaScript is a widely used high level interpreted programming language since 1995. Today it has become one of the most important and widely used client side programming languages. A study conducted by W3Tech states that JavaScript is being used at least on 88% of the web sites. It’s fair to say that any website created recently will for sure have some component of JavaScript. The responsiveness and interactiveness nature of web that we see today is partly because of the use and advancement in the JavaScript technology. Tools like jQuery, Angular, Backbone have made using JavaScript easier to implement for masses hiding much of the complex nature of JavaScript and it’s interaction with the DOM.

While it’s true that everyone loves JavaScript and you can’t even think of creating a new website without one, it comes with it’s security concerns. You might have heard that “JavaScript is Dangerous”. While that’s true but so is any other programming language. Sure due to the nature of client side script and how it the browsers processes it, it might be more prone to hacks and flaws but as a developers we can be more vigilant, understand the threat and follow best practices to minimize this risk. One solution that’s still thrown out is to “Disable the JavaScript”. In my opinion we need to get over this and embrace the security challenges. Sure you can disable the JavaScript and browse a crippled website which won’t even function in most cases.

JavaScript can be abused in a number of ways leading to theft, snooping your activity and privacy. One of the recent well known breach happened in 2012 when a couple of researchers sampled 5 million Facebook users in an attempt to find who who started typing the post but decided not to post it. The intent was not malicious but you can see how they could have easily captured what the user was typing and saved in on their servers. They did this by embedding JavaScript code that looked for on key down and on blur events on all textboxes within Facebook website. Another easily abused area is that of cookies. It’s a well established fact that organizations use cookies to store user information and many times it is enough to uniquely identify who the user is. If a hacker is able to embed JavaScript that can read cookies is any website it can retrieved the information that’s stored in them. Perhaps the most common form of attach is the cross site scripting attack XSS which I wrote about in the Week 6 blog post.


SQL Injection — February 5, 2017

SQL Injection

Week 8

A SQL injection attack consists of embedding or inserting malicious SQL script from client to the server application. The most common case is that of input fields where the hacker may insert SQL script in a for example username or password text box. If proper controls and precautions are taken the SQL script will make it to the server application and execute the script against the database. There are a number of consequences associated to a successful SQL injection attack. Some of these are listed below:

  • Read/Insert/Modify/Delete the data from the database. This basically means it can perform the CRUD operation against any database table.
  • Execute administration scripts against the database. For example in SQL Server a hacker might execute such as DROP, ALTER, DETACH databases or even shut down the SQL Server by executing the SHUTDOWN command.
  • Steal sensitive information or get access to confidential information by bypassing the login screen.
  • In some cases it may also be able to execute commands to the Operating System.

SQL Injection attack according to many published resources ranks consistently in the top 10 most common vulnerabilities. Veracode in it’s “10 Scariest Vulnerabilities”  ranks it at number 9. SQL injection is fairly easy to execute and it’s complexity really depends on the creative thinking of the hacker. It is most common in web applications, however in recent years .NET and Java applications has taken a number of steps to minimize the threat posed by SQL Injection.

Let’s take a simple example of how SQL Injection is executed. Let’s consider a web application needs to display the user profile of a specific user. The user is identified by a unique id which is passed through a Query string to the server. In a nutshell the code may looks as follows:

int userId = Request.QueryString[“UserId”];

string sql = “SELECT * FROM USERS WHERE UserId = ” + userId”;

The first statement grabs the user id from the URL and passes it to the SQL Server to get the information of the specified user id. If all goes well this will return the information of only the user requested by the user id. Let’s see how this can be changed to insert SQL Injection. The hacker instead of passing for example user id “100” in the URL may pass something like below:

“100 OR 1 = 1”

The “1 = 1” statement when executed in SQL Server will always result in a true statement. This would mean that return me the user with user id “100” and everything else from table. The final SQL script will look as follows:

string sql = “SELECT * FROM USERS WHERE UserId = 100 OR 1=1;

This will allow the hacker to get information about all the users in the system causing a major vulnerability to be exposed.


Cross Site Scripting — January 30, 2017

Cross Site Scripting

Week 7

Cross site scripting commonly referred as XSS is a web application vulnerability that allows the attacker to execute malicious JavaScript on the client web browser. This is major weakness how the web technology works where the client script can be manipulated by the attacker. The main concept of XSS attack is to embed malicious code in the client code of web application and execute it when the page loads or a certain event or an action occurs. Today XSS is one of the most common vulnerabilities today that is easy to exploit by even a naive hacker. Developers must pay close attention to the client side script and ensure measures are placed on the client and more importantly on the server side code.

How does XSS attack occurs? In a typical web application scenario, the user submits a request from the browser to the server, the server processes it and returns back a confirmation to the user. For example the user might fill out a registration web form consisting of typical user profile fields, the server processes the request and echoes back a confirmation message such as “ was created successfully”. A hacker might inject JavaScript in the email address field, it will get processed on the server and returned back to the user. When the control return backs to the browser it will execute the malicious JavaScript that was embedded by the hacker. This is the simplest form of XSS attack and is commonly referred as reflective XSS. In a real world example the attacks are much more sophisticated, for instance the attacker might inject script in a URL that user clicks and before the user submits the form to the application the malicious script may send the data elsewhere as well. A more serious attack may occur when the user profile form is saved in a permanent storage on the server for example a database. In such a case the malicious code will also get stored permanently  and will execute each time the data is loaded. This type of attack is called persistent XSS and has much wider consequences than the reflective.

Now that we have understood what XSS attack is, let’s take a look at some of the ways XSS can be prevented or at least make it difficult for the hackers to implement it.

  1. Sanitize, Sanitize, Sanitize the input fields. I can’t stress on this enough, if the developers get this right it will prevent most XSS attacks. Make sure on both client and server sides field validation is done. For example if the field is email address ensure it can only take email address and nothing else. If anything else is detected reject it right away.
  2. Encode and decode input/output data. Even with sanitization there will be cases where you need to allow open text. For example you might have a comments field that must accept alpha numeric characters and some special characters. In such cases make sure you encode the data as soon as it is received by the server. This means characters that are commonly used to execute JavaScript such as <, > should be encoded as &lt; and &gt;
  3. The last resort which I frankly think is not a valid option is to allow the users to disable JavaScript completely. Few years back this might have been a valid case but these days websites rely heavily on JavaScript and if they’re disabled the site pretty much becomes unusable. The reality is the web today relies heavily on JavaScript, the developers should take appropriate measures to secure it.




Continuous Integration Security — January 22, 2017

Continuous Integration Security

Week 6

Continuous Integration (CI) is a software development practice which merges copies of user codes into a main streamline multiple times a day. Each iteration of a “check in” by a user is run through build automation and verified. This is quite a departure from traditional software development practice and is something that is quickly becoming mainstream. Even though CI methodology was introduced in 2001, majority of the organizations opted for conventional development life cycle. However the trend is changing fast and based on a 2013 study conducted by Actuation Consulting Research it states that at least 74% software organizations are using CI methodology.

CI methodology presents security challenges where it’s not feasible to conduct security scans at the end of sprint or when an internal release (IR) is scheduled. For example typically a static scan may be executed on the binary files to detect for vulnerabilities. The main issue arises because CI by it’s definition is “Continuous” and security scans should be build into the CI process. When static scans are integrated in CI build, this is where Continuous Integration meets Application Security. The end goal is to make the process effective and detect security vulnerabilities as soon as possible. If any vulnerabilities are found as part of a CI build, it will be rejected and notified to the development team.

So how do we go about automating this process? Organizations like Vera Code, Core Security and Check Marx provide APIs that the development groups can integrate as part of the CI process. As soon as the build is completed the binaries are send to the Vendor platform via APIs which scans them for vulnerabilities. If any vulnerabilities are found the build is rejected and proper notifications are sent out.

The benefits are obvious. The security vulnerabilities are detected as soon as the code is completed by the developer and checked in. The developers are informed right way that what you checked in doesn’t meet security best practices and must be addressed before it even goes into the application. Fixing issues while the code is still in development is quick and cost effective.


Ethical Hacking — January 15, 2017

Ethical Hacking

Week 5

Computer hacking is a practice with many subtle differences. Many organizations in diagnosing the root cause of an hack try to get professional services of the hackers. A hacker in most cases will be motivated by whoever is sponsoring his or her actions and won’t care much about why his or her services are requested.

Ethical Hacking is used to describe a hacker who purposely tries to hack the organizations security system on their behalf. The computer security industry also refers them as “white hat hackers” to differentiate them from the “black hat hackers” who intent to inflict evil. It’s important to understand clearly what constitutes ethical hacking as many black hat hackers claim to be as ethical hackers when caught. Ethical hacking always must have a written agreement with the hacker and the organization and the goals should be well established. Another form of hacking is referred as “hacktivism” where the hacker is not motivated by money but rather does it as a hobby and social activism.

For our discussion the main question is why use ethical hacking as part of software development process. Why pay someone to for example hack your own site? The answer is quite simple: to prevent a crime you need to at least pretend like a criminal. When you hire a hacker to find security vulnerabilities you’re tapping into the same mindset of a hacker but instead they report the vulnerabilities to you. In application security ethical hacking is considered part of penetration testing, more specifically as part of manual tests where the white hat hackers try to exploit security flaws in the system.