Introduction to security vulnerabilities

Here is my presentation on “Introduction to security vulnerabilities” given at VodQA Shots, Hyderabad. The theme for the conference was “Security: Towards a safer web world”.

 

This presentation was accompanied by demo of an application vulnerableto XSS and SQL Injection. The code can be found at this Github repository.

Advertisements

Recommended reading – Developers interview at ThoughtWorks

I have been helping with recruitment in ThoughtWorks for quite some time now. Based on my experiences of interviewing developers, following are some links I would recommend everybody should go, or have just skim through while appearing for an interview at ThoughtWorks.

Note: This is not a exclusive list by any means. I have tried to keep this list as programming language agnostic as I can. All of the points mentioned below are absolute basic knowledge to have. Advanced topics are usually covered in the interview based on the experience and expertise of the candidate.

About ThoughtWorks

ThoughtWorks website
About ThoughtWorks
ThoughtWorks Products
ThoughtWorks stance on social and economic justice

Object Oriented Modeling and Design

Object Oriented Analysis and Design – Wikipedia
Classes and Objects
Analysis: Finding the classes and objects
How to find the classes
Domain Model – Wikipedia
What is Domain Modeling
Employing the Domain Model Pattern

Data Structures

Data Structure – Wikipedia
List of data structures
Data Structures – Fundamental Tools
Data Structures and Algorithms: When To Use What?
An Extensive Examination of Data Structures

Programming general

Programming Languages – Introduction – Wikipedia
List of Programming Languages – Wikipedia
Intro to Programming Course In Java – Udacity online course
Object Oriented Programming – Wikipedia
Intro to Object Oriented Programming
Functional Programming – Wikipedia
Functional Programming – Haskell Wiki
Functional Programming Principles in Scala – Coursera online course

Clean code and Refactoring

Code Refactoring – Wikipedia
Online catalog of refactorings
What Is Refactoring
Code smell – Wikipedia
Code smell
Code Smells – Coding Horror

Web Programming

Web development – Wikipedia
Web development tools – Wikipedia
Web application – Wikipedia
Web application development – Wikipedia

Computer Networks

Computer Network
How does the Internet work?
How Internet Infrastructure Works?
What happens when you type in a URL in browser?

Software Engineering

Software Engineering – Wikipedia
Software development process
Waterfall model

Agile

Agile – The New Methodology
Agile software development
Manifesto for Agile Software Development
Principles behind the Agile Manifesto
Agile Methodology

Agile Practices

The Big List of Agile Practices
35 Agile Development Best Practices
Guide to Agile Practices

Agile vs Waterfall

Agile Vs. Waterfall: Evaluating The Pros And Cons
Agile & Waterfall Methodologies – A Side-By-Side Comparison
Agile vs. Waterfall
Waterfall vs. Agile: Which is the Right Development Methodology for Your Project?

Test Driven Development (TDD)

Test driven development – Wikipedia
Test driven development – Martin Fowler
The three laws of TDD
Introduction to Test Driven Development (TDD)

Extreme Programming (XP)

Extreme programming – Wikipedia
The Rules of Extreme Programming
What is Extreme Programming?
Agile Modeling and eXtreme Programming (XP)
Extreme Programming

Pair Programming

Pair Programming – Wikipedia
Agile Development Methods – Pair Programming
Guide to Agile Practices – Pair Programming
How to Pair Program
Pair Programming Benefits
Pair Programming Benefits – C2 Wiki
The Costs and Benefits of Pair Programming (PDF)

Useful blogs to follow

Martin Fowler’s blog
ThoughtWorks Insights

Books

Refactoring – Improving the Design of Existing Code
Clean Code: A Handbook of Agile Software Craftsmanship
Growing Object-Oriented Software Guided by Tests
Structure and Interpretation of Computer Programs
Domain-Driven Design: Tackling Complexity in the Heart of Software
Test Driven Development: By Example
Extreme Programming Explained: Embrace Change – Bookk by Kent Beck

Application Security: The Agile Way

Agile showed a great way of building projects in an iterative fashion. Benefits of using Agile processes over waterfalls are evident.

However, even though agile projects have existed for years, the approach to security on these projects has remained the same as waterfall. Security testing / penetration testing is still big bang, just a week before release of the project.

There are some fundamental problems with the existing “waterfallish” approach to application security. Some of them are:

  • Penetration testing very close to release, leads the developers and business finding workarounds for the vulnerabilities in a rush instead of patching them properly. This often leads to multiple unpatched vulnerabilities in long run. Also, there is a possibility of the workaround for one vulnerability making another component vulnerable.
  • Sometimes security problems are result of the architectural decisions. For example, sending the current user password in plain text for “Forgot password” functionality. By the time these security vulnerabilities are uncovered, it might be too late to change the architecture.
  • If the components / dependencies used (for example, libraries) have known vulnerabilities, it might be difficult to change them just before the project release.

Problems such as the ones mentioned above poses a very important question. What would it take to do application security the “agile way”?

In order to answer this question, the following points seemed imperative.

 

Developers who knows how to write “secure code”

Most of the security problems would be avoided if developers know and write secure code. Every time developers write code to accept user input, they should think about validation. Every time they needs to store customer data into database, they should think about the sensitivity of the data and the need of encryption.

Knowing about OWASP Top 10 vulnerabilities is a must. And then there are some great resources for developers to learn about secure coding practices. My favorites are:

 

“Security expert” on the project

Let’s agree that no matter how much a developer tries to learn about secure coding practices, there will always be something in the code which only an experienced eyes can catch. Hence, it is advisable for each team to have at least one designated security expert who is reasonably experienced in the field of application security. The required experience level can vary based on the complexity and the number and type of “sensitive points” of the system, but the more experienced the security expert, the better.

Usually the role of security expert includes:

  • Pairing with other developers on developing security sensitive stories.
  • Uncovering and conveying different ways to break the system to the developers. This also means fixing the problems before the code is even checked-in into version control system.
  • Taking part in the discussions on choosing libraries to use, deciding contracts with external systems, deciding public APIs, etc.
  • Helping Quality Analysts to test security sensitive stories.

In addition to these tasks, the security expert is also expected to help in building secure code writing practices and security testing capabilities with the team.

 

“Security Sensitive” stories

In Iteration Planning Meeting, at the beginning of the each iteration, security expert (with the team) should mark stories involving security related design and decisions as “security sensitive”. Some sample scenarios in a story that must be marked as security sensitive are:

  • Introducing a new user input field (text, dropdown, etc.)
  • Storing user input to database
  • Invoking external processes or system commands
  • Processing data received from external system
  • Dealing with authentication and authorization process

 

Abuse cases for each security sensitive story

Every story has acceptance criteria. For security sensitive stories Business Analyst (with the help of security expert) should write acceptance criteria from security point of view. Similar to Use Cases, Security expert is expected to write abuse cases around the functionality. This ultimately helps Quality Analysts to write test cases from security testing point of view.

 

Security testing before a story is “accepted by business”

When a security sensitive story moves to “in testing”, Quality Analysts must test the story for abuse cases to check expected system behavior. Security specialist can help Quality Analyst in this. Of course, this testing has to be done along with functional testing of the story. If a vulnerability is found during the testing, the story must be moved back to “ready for development”. Then developer fixes the vulnerability properly and moves the story again in the “ready for testing” lane. And the cycle continues. Once story is tested for all the functionality and no vulnerability and loss of functionality is reported, the story can be moved to “accepted by business” status.

 

Automation or no automation?

Automation of security testing is a very controversial point of discussion in the field of security. Some believe there is no replacement for human testing, whereas some believe there should be a full automation for testing.

I personally believe that there is a middle ground. Of course we need a security tester to find the vulnerabilities in the system. But once found, security testers should write automated test so that they will never need to test for the same vulnerability again in the same part of the system. Tools like OWASP Zed Attack Proxy can be helpful in writing such automated tests.

 

Conclusion

It goes without saying that we should build security into the application than around the application. Using the pointers above, we were able to successfully deliver relatively more secure system. We did have a “conventional” big bang penetration testing just before the project went live. But as expected, we did not have any high (or even medium) priority vulnerabilities reported in the system.

From the customer’s point of view, this process gave them a high confidence in the security of the system. A major point to note was that, there was no deadline slippage because of the security issues.

Finally, there is no silver bullet which can be applied to all projects. The whole point of being agile is that, it gives us opportunity to change or modify the approach which is best suited for the system under development. This post can be considered as a pointer on what is the minimum we can do in to bake security into the system being developed in agile way.

Find subdomains of a domain name

I often needed to find sub-domains of a domain. Simple Google search for any tool doesn’t return any good results. There are couple of command line tools which does some brute forcing. But they are painfully slow.

I found another easier way to do this using Wolfram Alpha.

  1. Visit http://www.wolframalpha.com
  2. Search for the domain you want sub-domains of. For example, htc.com
  3. Click on “Subdomains” tab in web statistics section.
    Subdomain link on WolframAlpha
  4. Wolfram Alpha will list of known sub-domains of the domain
    List of sub domain names

Of course, it might not list all the sub-domains, but this should be a good enough starting point without going to the command line. 🙂

Download videos from InfoQ

InfoQ has amazing collection of presentations from different conferences. I love to watch these videos.

The problem I have is I don’t really have a high speed Internet connection at home. Thankfully, my employer ThoughtWorks has very high speed Internet line in office. So, downloading video in office and watching it at home seems like a very good option.

InfoQ doesn’t have a download button as such for these presentations. Somebody has written python script for this. But I wasn’t able to install bs4 package on my Mac. 😦
So, I created a small shell script for my own to get the URL of the video. 🙂

This script is no way perfect. And yes, I know it’s a very dirty code. 😉

Enjoy!

Custom shell commands with wildcard characters in Go CI

For your build pipeline, ThoughtWork’s GO let you define tasks to invoke a shell command or script. This is extremely useful for tasks such as ssh’ing or scp’ing files to deployment servers.

For this post, we will take example of SCP.

You can setup task to scp a single file as shown in following screenshot:

For single file uploads, this work perfectly fine. But if you want to upload multiple files (for example, all zip files in the folder), you would like to specify it with shell wildcard characters like * or ?.

Unfortunately, this does not work. We get following error with above settings:

dist/*.zip: No such file or directory

The problem here is Go internally puts all parameters inside single quotes(‘) while executing command. So, even if you intended the command to run as

scp dist/*.zip user1@my_server.com:/home/user1/deployment

the actual command which gets executed is

scp 'dist/*.zip' 'user1@my_server.com:/home/user1/deployment'

As the parameter is inside single quote, shell will not try to interpolate the wildcard character * in the command.

To overcome this limitation, you can use bash’s

-c

switch. This bash switch lets you specify a string which will executed in a shell’s context.

After specifying above settings, you can achieve the intended results.