A complete and comprehensive take on security today.

Retrospective: NASSCOM Cognitive Security Meet – 2017

With a rapidly evolving technology innovation landscape, a paradigm shift in our approach towards security is necessary. The transition of the outlook towards cyber security in India is changing from reactive risk mitigation approach to a more holistic readiness to protect against the escalating cyber threat landscape. Management attention of various organizations to Cyber security at the Board level in the Enterprise and PMO in Government has increased. The Best Practices Meet threw light on use cases and aspects of cognitive computing that are shaping the security technology market. The two – day meet touched upon topics like DevSecOps, GDPR implementation, cyber defense centers, AI, machine learning and the likes.

Mayank Lau and Shomiron Das Gupta of Data Security Council of India (DSCI) opened the first day with a  Cognitive security workshop. The workshop focused on bringing about the differences between using Machine Intelligence and Business Intelligence, finding patterns/insights in the data. It further emphasized on creating an ecosystem where capabilities of cognition could be used to deliver intelligent, lightweight products of minimal complexity.

DevSecOps, a practice that has been pegged as the antidote for security pain points in product development was deliberated upon in two panel discussions.  Echoing the very essence of DevSecOps that we45 has been practicing, it emphasized the role of DevSecOps in helping organizations develop quality and secure products by implementing security in the overall development process. It underscored the importance of setting up a common ecosystem for an organization’s activities which ease out security checks, patch management for security and the likes.

Security by design, a lean concept, was further explored by inquiring into methods like least privilege access, defense in depth, minimising attack surface, providing and maintaining traceability to requirements, threat modeling, usage of least vulnerable third party OSS components, usage of SAST and DAST tools, performing third party OSS vulnerability checks and so on. In addition to the principles of secure design, importance of security patch release management, patch management for AI modules, discovering unknown vulnerabilities , usage of Machine Learning to detect changes in the code for breach management were also discussed.

Amita from we45 in discussion with the panel

The second day opened with panel discussions on Cognitive security and self-learning systems.With the help of use cases, the discussion tried to identify the underlying capabilities and possibilities cognitive computing brings, the impact of cognitive computing in different domains and ways in which cognitive computing helps to tackle security problems.

Adding a layer of AI to Threat Intelligence and hunting operations was something that caught my fancy. The insufficiency of traditional signature based methods for attack detection, security solution evolving from being threat based to unified solutions, emphasis on technologies like AI, Machine Learning giving a significant boost to an organization’s security operations and threat intelligence centers and future of AI based cyber security were discussed.

A short, yet interesting session deliberated about “Reposing trust in the citizen identity system” – the session emphasized the importance of having a unique identification number, the security issue it poses. A  panel discussion between the security heads and lawyers saw many important questions being answered.

An interesting talk by Sahir Hidayatullah, CEO, Smokescreen, covered topics like adversarial machine learning, finding patterns and scaling, network isolation and cryptography, mirage maker, attacks against the ML algorithms, applying traditional military history methods to cyber security, threat hunting, reconnaissance, intersection of methods of defence and attack, Honeypots / deceiving the attacker, modelling based on the thought processes and actions of the hacker, early threat detection, freezing/isolating compromised parts of the system etc.

The event ended with a plenary session on the Ramification of AI, IoT, Industries 4.0, Blockchain and Encryption dominated world on life, society and economies and the need for decisive policy intervention.  They enquired into the need for India to bring these areas on its policy agenda and all the related issues to be addressed, the ongoing policy initiatives related to AI IoT Blockchain Encryption and Industries 4.0, the role of policy intervention to boost the development and adoption of these technologies.

The conference tapped into interesting areas of the ML ecosystem. As interesting as the test cases were, the translation of theory into implementable ideas was missing from the deliberations. It’s commonplace for practitioners to wrap cyber security and AppSec into the same fold but, addressing the diversity in applying AI to both these domains is the need of the hour.


Adding Security to QA- Completing the DevSecOps Puzzle

Global conferences such as RSA 2017 and the OWASP AppSec have convinced product engineering groups that “Security in DevOps” is the need of the hour. Security scanning tools & aggregation platform vendors are beating the drums on how their platforms bake  security into the development pipeline by integrating with continuous integration (CI) and defect tracking tools used by engineering teams.

Interestingly, Engineering & Security have ‘by default’ been the usual suspects in building security into the development pipeline. QA never figures in the mix as it is assumed that their sole focus is on verifying product functionality and usability. More often, QA’s angle to security is from a feature’s security verification standpoint. For example, QA would ensure that security enhancements, like a token based authentication developed by engineering as a feature is verified, but would not perform checks on its threat vectors.

In order to achieve the proverbial “shift left security” there is a need to integrate security as part of the Quality Assurance ecosystem, taking advantage of QA’s tight integration with engineering.

The first change in paradigm towards this would be to position security vulnerabilities as defects. These defects can then be prioritized based on the criticality of the vulnerability and the potential damage that it can cause. In a DevOps environment, builds are continuously tested and any defects identified by QA are automated by employing test automation frameworks.

Security teams can bring in efficiencies in their testing schedules (aka reassign saved bandwidth) by leveraging QA’s expertise in automation. Any defects found by security can be scripted and automated by QA. In many cases, a large part of automation scripts created by QA can be beefed up with security payloads, thereby reducing the effort of creating security automation scripts from scratch. Over a period of time these scripts would act as a repository of security regression scenarios that can be run against every build of the application.

Additionally, since functional use cases are drafted at the requirements stage, security teams can augment efforts by creating associated security abuse cases. An abuse case aims at mirroring the way attackers would view the application by mapping out risks/threats that the application would face from a security perspective. The co-involvement of security and QA teams at the requirements stage in designing security test cases along with functional ones will help in building security-minded QA teams.

This practice (according to research findings) brings down the cost of fixing defects by identifying them in the requirements gathering phase, as opposed to post-release remediation which could potentially result in significant design overhaul and regression defects.

Fortifying applications is a daunting task, nevertheless not an impossible one. An effective way to secure applications is not by stopping with one-time baseline pen-tests for identifying security flaws, but to keep “shifting left” with each passing iteration of release to ensure that from conception to production, every phase of SDLC is secure.

WannaCry in the AppSec World

There is literally no way anyone could have avoided hearing about “that ransomware attack” which crippled millions of computers all over the world. The WannaCry Attack has made waves across technologists and non-tech folks alike, and has made several folks definitely wanna cry, as they see their critical data encrypted and completely unavailable.
As a quick refresher, the WannaCry ransomware attack has emerged from the aftermath of the infamous Windows vulnerability MS17-010. An Attacker can send specially crafted messages using SMBv1 (Server Message Block), execute code on the remote server and gain access to the server as a privileged user of the computer. This affects multiple categories of windows products, including Windows Server 2008, 2003, 2012, XP, Vista, 10 and other windows OS products. The patch for this flaw was released by Microsoft in March 2017. However, it was only a patch for currently supported products and not older products like Windows XP, Server 2003 and so on, which still has a massive user base. The code from WannaCry is said to have emerged from the exploits stolen by a group known as the Shadow Brokers from the Equation Group (a cyber threat actor that is supposedly linked to the USA’s National Security Agency (NSA)). The malware, known as WannaCrypt0r has been used to perform the WannaCry attack.
The worm is extremely effective against unmatched Windows hosts, where it loops through the RDP sessions on the system, attempts to identify hosts on the network, loads the payload on the remote computer and scans the network for additional hosts to infect on port 445.
A detailed technical description of how wannaCrypt0r works is available here for those interested to read
Adrien Guinet, a security researcher has released a decryption tool on May 18 that will be able to decrypt the ransomware without the users having the pay the $300 ransom. This works on several OS variants, but not all affected variants: https://github.com/aguinet/wannakey
wannaCry is a wake up call for the industry and holds scary prospects for the application security world as well. With Applications, we use several third party libraries, frameworks and open source code that is often vulnerable to several security issues. In addition, vulnerabilities against these popular frameworks can easily be weaponized and used to decrypt sensitive/mission critical datasets for organizations. These can be fatal to organizations relying on these apps for their day-to-day operations. In fact, we saw a glimpse of this possibility when the Apache Struts2 Remote Code Execution flaw was identified, and everyone who got hold of the exploit used it to perform “tests” against any application out on the open internet.
I feel that its only a matter of time before ransomware payloads start making their way into Web Apps.

The Baby Steps of DevSecOps!

I’ve been on the road over the past 10-14 months speaking to security and product engineering teams on DevSecOps, Security in DevOps, Secure SDLC or Suzie as some might call it (doesn’t really matter anymore). I’m just going to stick with ‘DevSecOps’ for the rest of this article. For starters DevSecOps is no more the ‘new-kid-on-the-block’ from a conceptual perspective. Thanks to RSA 2017, concept selling as been on a such a high note that product engineering teams have been overwhelmed with much information to the extent that few of them think that DevSecOps is a cakewalk, few others feel that they’re behind the curve and the rest assume they’ve attained the nirvana! Interesting question at hand for the beginners – What is the HOP (before the SKIP and JUMP) DevSecOps?

It’s not all about the Tech

DevSecOps like security, (and almost everything else) has the mystic triad – Technology, People and Process. The pillar that’s obviously making the most noise is the technology angle of security automation – which are the scanners and the tooling platforms. Unfortunately the other two pillars form an equal, if not a larger share of the solution. Security and Engineering have forever been at loggerheads in getting a product release out to production. In most cases, engineering wins (after much deliberation) with release timelines taking a higher precedence. This (by design and by default) leads to security assessments being conducted either as an ‘end-of the-chain’ activity or at a frequency no more than twice a year – compared to >6 major releases in a year.

The solution to this classic Catch 22 situation is two fold – Visibility and Culture.

Contrary to usual belief – developers DO care about security (there, I’ve said it).They just need to be equipped to address it better.

Engineering teams are seldom equipped with the necessary artillery to have a go at security issues unlike functional issues. A key bottleneck that developers face while solving security issues is “replication”. Often times, a developer looking at a P1 bug has no way to truly ascertain if his/her remediation is successful. This leads to a frequent back and forth ‘bug validation’ between security and engineering taking precious project bandwidth. The other aspect is prioritisation. There needs to be a common baseline (strengthened by platforms of course) that project vulnerabilities that are truly valid. More often engineering are presented with a laundry list of bugs with more than 30% of them having a low probability of impact, which take up significant engineering bandwidth for remediation. Finally, one cannot overlook the fact that “DevSecOps” demands a significant culture-shift in the way engineering works, and its about time the security community starts appreciating /empathising it. The first step in security automation is to internally “sell” the value of automation across the board. There needs to be tangible value to everyone in product engineering.

  • How / How much can engineering ‘Find Early & Fix Early”?
  • How can security teams make better use of their existing security investments (Technology and Skilled Resources)?
  • How can we minimise the amount of re-invention needed by DevOps team to include security automation at the pipelines?
  • What are the feasible integration points in the existing Agile/ SCRUM processes?

Fine Tuning

I (and I speak on behalf of my team) have always been fascinated by applications. No two e-commerce sites are the same. The motivation of a dating app’s architecture is vastly different from a mobile social platform. It is this pervasive and dynamic landscape of applications that makes securing them both challenging and interesting. Add to this a flavour of continuous automation. I think I speak for a community at large when I say, there is no ‘off-the-shelf-standard-one-size-fits-all’ framework for DevSecOps that works perfectly at a granular level for product engineering teams across the board. However, what would definitely work is to have a reasonably sound, underlying skeletal structure that can then be customised to a focus application.

To start off, product engineering teams (engineering + security + DevOps) need to arrive at a realistic ‘automation frequency’ during the early stages of adopting DevSecOps. Assuming the current frequency of manual security assessments performed for a product is once a year, it is next to impossible for the team to aim at implementing a system that performs automated security assessments for every release (twice a month) within a 12 month time period. This again goes back to an understanding that DevSecOps is not ‘just plugging technology components’. In the initial stages, a well defined implementation plan should aim at achieving security automation at a frequency thats a reasonable stretch from the current frequency of manual assessments. In the above example, a reasonable goal could be to expect the framework to cater to accumulated product releases say thrice a year. An alternate (if applicable) model would be to implement the system for certain modules of a larger product, perfect the system over a couple of months and then throw in the other components. Either which way, the essence is to start small and not overwhelm.

Another key element in the SKIP phase is to ensure that existing technology investments (like DAST/ SAST scanners, automation platforms, CI services, bug tracking platforms etc) are extended to their fullest capabilities to work in an integrated model. The corollary statement – to ensure that any newly procured technology platform, integrates seamlessly with the automation framework.

Build – Operate – Transfer

Finally, it is fundamental that engineering teams are equipped with the necessary skills required to continuously ‘review and tune’ a DevSecOps framework. A truly successful implementation of application security automation system is one that has minimal dependance on third party solution providers in the long run. Security automation technology firms should devise engagement models that are self-sustainable and maintainable by product engineering teams.


This blog was originally published on LinkedIn by Rahul.

OWASP Top 10 2017 and the new age of Application Security

We, in the security industry love the OWASP Top 10. For one, it has a catchy name. But more than that, it has a simple way of grabbing people’s attention and focusing them towards application security using the concept of a simplistic list. The OWASP Top 10, released by the Open Web Application Security Project every four years, has become a benchmark that the entire industry rallies around, for application security. So much so, that the OWASP also has similar lists for Mobile Application Security and IoT Security.
OWASP has created its first Release Candidate (RC-1) for the year 2017. While this document is still under review and is open for comments from the community, it is a complete document that will probably have minimal changes, if any before it is released to the world.
What’s the OWASP Top 10?
For those who are not aware of the OWASP Top 10; The Open Web Application Security Project (OWASP), was founded in 2001 as a not-for-profit organization. OWASP is an independent body of industry professionals and application security leaders who come together and contribute to a single cause. Making applications more secure. OWASP and its community has a prolific output of application security artifacts in the form of articles, books, tools and so on. They have conferences across the globe where leading minds in application security discuss the latest and greatest techniques and practices in making and breaking secure apps.
One of OWASP’s most enduring documents is the the OWASP Top 10. The OWASP Top 10 is a document that captures the key risks and weaknesses that are facing apps all over the world at a given point in time and capturing the Top 10 categories of application security risks. This document is used extensively by organizations and security practitioners all over the world. Not only does it provide a detailed analysis of security risks to applications, at a given point in time, but it also provides specific details capturing the nature of the risks, including Exploitability, Prevalence, Detection, etc. thereby creating a more holistic view of security risks, rather than focusing only on the “weakness” per sé.
What’s new in the OWASP Top 10 2017?
The OWASP Top 10 2017 is important for many reasons. In my opinion it has highlighted and captured several key elements of information security that are relevant for today’s apps. Let’s take a look at some key changes in OWASP Top 2017 vs OWASP Top 10 2013.
Merging of Access Control Based Vulnerabilities
Attacks against access control are one of the key ways in which hackers look to compromise applications and gain access to sensitive information. Since 2015, we at we45 have seen a dramatic increase in Access Control attacks as compared to most other classes of attacks, including Cross Site Scripting and SQL Injection, with the latter becoming rarer and rarer, simply because modern application frameworks automatically perform encoding and parameterized SQL queries using ORMs (Object-Relational Mapping). Attacks against Authorization, like Insecure Direct Object reference attacks and Authentication Attacks, against sessions or tokens is a more pernicious set of attack vectors, especially with Single Page Applications and API-style applications becoming the norm. Access Control hasn’t been made into a highly generic style of security protection, as developers implement their own access control routines. The OWASP Top 10 rightly classifies all access control attacks including authorization flaws under a single category called “Broken Access Control”.
Under-protected APIs
With the rise in client platforms and distributed computing, the world is clearly moving towards creating APIs as opposed to typical browser-focused web applications. APIs are the invisible glue that bind multi-platform/client applications to a particular set of web services, be it mobile apps, Smart TVs or other applications. While APIs might be web applications, securing APIs is a little different from securing typical web applications. There could be a bevy of attack possibilities for APIs ranging from the standard injection attacks to more complex authentication bypass flaws, token based information disclosure flaws and access control flaws. Flaws like XML External Entity Injection, where a vulnerable or poorly configured XML parser can be leveraged to perform devastating attacks against the application can be leveraged against Web Services or API-style applications.
Insufficient Attack Protection
This is a departure for the OWASP Top 10. While the OWASP Top 10 typically focused on Application focused risks, this OWASP category is typically “outside the application”. This category focuses on “detecting, responding to, and blocking attacks makes applications dramatically harder to exploit”. I for one welcome this, because there are fundamental flaws in Application Security programs used by organizations, where there is too much focus given on preventive security measures, and hardly any time and effort put in to detective and corrective security measures. Detection includes techniques like Vulnerability Assessment, Penetration Testing, Deploying WAFs or RASPs and corrective refers to releasing virtual or real patches for the flaws to protect against attacks.
One of the other challenges with today’s distributed apps, is the challenge of monitoring. Monitoring complex, distributed apps is an art that most companies don’t get right. However, with ready tech available in the form of the ELK stack (Elasticsearch Logstash and Kibana) or Splunk, etc, this has become much easier to do today, than ever before.
Continuous Application Security Testing 
At we45, we couldn’t be happier at this year’s OWASP Top 10. It has reinforced an age-old tenet that we have been advocating to the community at large. Today’s apps are usually in rapid-release, agile environments where apps undergo constant changes in the form of new features, UI and so on. There is a need to ensure that apps are continuously tested for security vulnerabilities. This can be in the form of leveraging automation for SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing) and creating automation for manually identified exploits as well. This is the essence of Security in DevOps, which promulgates that application security vulnerabilities should be discovered earlier in the lifecycle, rather than later, where the security flaw might make its way into production, causing a great deal of disruption.

The Most Secure Application Development Language

One question that several people have asked me over the years is this “Which is the most secure development platform/programming language in the world?” It is an honest question. It is quite pertinent, given the state of application security across the globe. However, it is akin to asking the question “Which language allows me to speak the best?” The answer to that question is “all of them” or “none of them”. Today, on the web, we have several languages/platforms/frameworks vying for attention. All of these languages have their disciples and zealots. Yes, you even find them for languages like Perl (to be taken in the right spirit). Nevertheless, I would like to provide a glimpse into the current state of security of these programming languages and platforms, to give the most suitable response that I can provide for the question that most people ask me.
Firstly, let me start off by saying this. In my opinion, programming languages and platforms are like tools. A skilled and security-conscious developer can do amazing things with these languages and platforms. I can safely say that a developer who is aware of security requirements and their impact on an application, is truly the best defense against attacks. However, that is not the purpose of this article. For this article, I will divide my analysis into two segments, they are:

  • The Established Order
  • The New(er) Kids on the Block

The Established Order

The Established Order consists of languages and frameworks that have been used since the inception of web platforms. I am principally referring to Java, ASP.NET and PHP. I am going to ignore CGI and Perl simply because, I believe that most modern development across companies that I encounter do not depend on.

Lets start with PHP. PHP is a security tester’s dream. I have seldom found a secure PHP application that I have truly respected for its security implementation, which is scary because PHP is an extremely prevalent programming language on the interwebs. In addition, the simplicity of the language and the sheer number of PHP products (WordPress, etc) dominate the world of the web. An established PHP developer told me that the reason that PHP is so widely maligned from a security standpoint is that the language is splintered and distributed (a claim that I am not entirely sure of). Nevertheless, I find a rash of vulnerabilities with PHP applications and I can safely generalize that I find most of the highly vulnerable applications developed on PHP. Having said that, newer implementations of PHP that use frameworks like Zend and CakePHP seem to have handled several issues that we used to encounter on a routine basis.

Java has gotten a status of being an “enterprise platform/language”. I have seen Java either being used by Banks and Financial Institutions or established internet companies like Amazon and Google. I have observed that while Java devs seem to have handled Authentication issues, session management implementations with great comfort, I have seen several failings in Direct Object Reference attacks and Cross Site Scripting. The good thing with Java is that you have a great deal of code examples, lessons and tutorials on securing Java Apps, however, I still find that XSS and Direct Object Referencing issues are pervasive across most Java Apps that we test at we45. Java provides great strength with reference to Crypto and I find that log4j single-handedly simplifies Logging and Log Management for Java. However, more programmatic security issues still persist with older Java web apps. Today, we have some great Java web frameworks like Spring, Play and Vaadin that handle several security issues right out of the box.

ASP.NET is a surprise on the web platform front. It is also an extremely popular and powerful platform that has been used extensively in several applications that I run into. Although one might scoff at Microsoft for its security flaws (in the OS), they have done great work with promoting and promulgating security features into the platform. I see very few issues with XSS, SQL Injection, Session Management, etc with DotNET, However, I still see Business Logic, Direct Object Reference and Authorization Flaws with the platform. I also find that DotNET Developers are more aware of security issues and impact as they seem to have several security references in their reference materials and API Documentation.

The New(er) kids on the Block

In this section, I focus on languages/platforms like Python (Django), Ruby on Rails, Angular, Node and so on. While some of these languages are not exactly “old”, I have seen some modern applications and new-age product companies use these platforms and frameworks in their products.

Let’s start with my personal favourite, Django (Python). I love Django. It is extremely simple and abstracts away all of the niggling security-related issues that you see requiring explicit attention with other platforms. Django pretty much solves XSS, Password Encryption, SQLinjection, Session flaws, Auth flaws, XSRF and Host Header Injection right out of the box. Its less verbose and highly effective to be used even for apps with massive scale (we45 ’s own apps VMA and SecuritySlate are 100% Django and scale like nobody’s business). However, all this security sometimes dulls developers into thinking that they are invulnerable and they make serious errors in Business Logic Flaws, Direct Object Reference and other flaws. In addition, Django does not directly allow the use of Indirect Object maps, which makes fixing Direct Object reference flaws, a little cumbersome to say the least.

Ruby on Rails has made some impressive strides in security. However, some of you might remember that Github had massive security failures due to some insecure implementations of ActiveRecord and Mass Assignment in Ruby on Rails. Ruby on Rails devs also had some security nightmares in 2013 (read CVE-2013-0156). However, in my opinion things have been rather quiet on the Ruby security front since then. Ruby also enjoys some great APIs and apps that really make a developer’s life easy when implementing security. Apps like Brakeman and Codesake are highly used and appreciated by the Ruby Dev community. Rack is a middleware component that enjoys massive usage for its inbuilt security protections.

Angular JS and Node JS are defiinitely new kids on the block as they are used by the latest apps. They are usually used in conjunction with NoSQL Databases. I find that NoSQL databases are implemented in a very in-secure manner and thus we (at we45) find issues with these applications. We also see CSRF Issues and Web Services Auth Bypass issues with these apps. We also see HTTP Parameter Pollution with AngularJS Apps implemented with NoSQL quite often. Of course, we see some XSS attacks as well.

I think by now you would have understood that languages/platforms and their frameworks can facilitate security and its implementation. As I mentioned earlier, the most important defence against an application’s attacker is a skilled and security-conscious developer and an organization that has planned, implemented and tested security extensively across the lifecycle. No language/platform or framework can serve as a defence against negligence and lack of awareness.


I am in the airport at San Francisco writing this blogpost. Over the last 2 weeks, I have constantly been in meetings with some of the most important companies in the regions, the hot product companies, the “unicorn” startups and more. If anyone has been around the valley since 2014-2015, the buzzword is “DevOps”. DevOps is rapidly gaining traction as the most essential attribute of application development and deployment, since….well, application development and deployment. However, I while companies (large and small) are taking to DevOps implementations and practices extensively, they are going through the same set of issues that plagued them in the old paradigm, specifically in terms of Security. Let me get to that in a bit. But first, a little bit of context….

What is DevOps?

Agile Development changed everything in the world of applications. Using simple steps and a result-oriented approach, application developers were able to move away from the waterfall model (a practice that frankly sucks due to its high potential for project failure) to how things really work (Agile, in rapid application development lifecycles). Everyone today (including some of the stodgy, luddite corporations) are embracing the Agile model of Application Project Management, which is built on the premise of rapid application development and deployment. As agile was gaining traction, it was seen that the people and processes involved in Agile development, were still structured around the old waterfall methodology, with business stakeholders, developers, architects, QA, testers, operations, all functioning as separate units with little interaction and collaboration with each other. This of course, was anything but agile, and soon, a new way of working was identified. This is DevOps. DevOps is a series of practices, technologies and processes that involve a high degree of collaboration with the different teams involved in agile development to facilitate rapid application development. This essentially meant that business, devs, architects, testers, ops, etc work together using amalgamated practices to leverage high performance in the application development lifecycle. This leveraged practices like Continuous Development, Integration and Deployment, which means a high degree of orchestration in planning, development, testing and deployment. Especially in the cloud, these practices can be highly beneficial for organizations, resulting in nimble and truly Agile application development. This has resulted in the creation of a separate position in the organization which is focused on DevOps.

This sounds great… What’s the problem?

It does sound great, and it is. DevOps has resulted in incredible benefits for its adopters. Technologies and practices around Continuous Integration (CI), Continuous Deployment (Machine Orchestration) has been hugely beneficial for organizations that have large/complex application environments on and off the cloud. However, as is always seen with a disruptive IT industry, security is usually forgotten. Recently, a hot healthcare product startup came to us for some consulting and penetration testing. They had deployed their infrastructure on Amazon, with an analytics and search layer using ElasticSearch. They had developed an app that was slated to be delivered to some large hospitals in the US. They had a DevOps team that was handling all the orchestration between their various components, that were many and quite complex. Mid-way into the penetration testing, we had already found a rash of Object reference vulnerabilities, crypto flaws and worse, we were able to exploit their vulnerable ElasticSearch instance and completely compromise their Amazon VPC. So, the natural questions that emerged from our consulting engagement with them subsequently, were on the lines of:

  • Do you do some security planning in the planning stage of your sprints and backlogs?
  • What kind of security vulnerabilities do you identify to be critical for your app and environment?
  • How do you identify vulnerabilities in third party components and remediate?
  • How does your Continuous Deployment process handle security challenges?

When the answer to all these questions was met with a pregnant pause, we realized that they clearly had missed all/most of them. Over the last 2 weeks, I have been observing similar trends with most appdev projects or product companies that we have spoken to.

That sounds bad….What do we do?

The good thing is that there is something you can do about it. One, realize that DevOps without security built-in is just an accident waiting to happen. You may have rapid development and deployment cycles, but without Security in DevOps or “SecDevOps”, you are rapidly developing and deploying non-secure apps, which is worse than the non-DevOps state of affairs. Here are some practical steps that you can take. In our engagements with clients involved in DevOps, this is what I have seen working pretty well.

Dirty Threat Modeling

There was a time when I would have advocated a well-laid out Application Risk Assessment plan, but the reality is that in a rapid development lifecycle, Application Security Risk Assessment just doesn’t work. Its slower and people just stop following it. During your product Backlog, you need to do a solid, quick and dirty threat modeling that becomes a template for your entire lifecycle. We have done a ton of assisted threat models for clients, and this works, especially if you do it with some hardcore metrics.

Fix DevOps Awareness

Most Companies try and fix Developer Awareness. This is not nearly enough in a DevOps world. DevOps uses a ton of technology and practices like CI (Jenkins, Travis, Bamboo, etc), Continuous Delivery (Chef, Puppet, Ansible, etc), and a ton of other home-brew stuff on the cloud or on premise. Training and security awareness for the entire DevOps process is essential. I have seen more than a 70% reduction of security incidents, when we have done DevOps oriented security training for our clients.

Continuous Security Integration

Continuous Integration is an amazing practice. It has changed the way apps are developed and tested. However, it is seldom leveraged for security. At we45, we have developed some significant way to do “Continuous Security Integration” which involves creating custom security automation and powerful security validation practices that integrate with CI. This ensures that security vulnerabilities and bugs are caught early and frequently, ensuring that you don’t have the tail-end surprises emerging from a pentest. This itself can be an area of great depth. More on this in a later article though….

Security in Deployment Orchestration

Many companies that we work with use some sort of Continuous Deployment framework like Chef, Puppet, Ansible, SaltStack, etc. However, security is a critical underlying practice that needs to be integrated into cookbooks or automation scripts used in each of these frameworks. This is critical, especially when you have a large number of moving parts in your application environment.


DevOps is here to stay. However, without security, it will be rudderless and worse, dangerous. Security in DevOps or SecDevOps really is similar to the age-old concept of developing security right from inception. The cycles, practices and technologies need to be tweaked to ensure that security is smoothly integrated with the cycle. This as always, takes some discipline, some automation and some management.


Technology is changing at a rapid pace and companies are always looking to adopt newer technologies that may be easy-to-use, more convenient for their customers and so on. However, these technologies are often implemented without considering security

AngularJS is a front end component of the popular MEAN Stack (Applications created with MongoDB, ExpressJS, AngularJS and NodeJS). The main aim of using AngularJS is to simplify the representation, development and testing of applications. It provides a framework for client-side model–view–controller and model–view–view model architectures, along with components commonly used in rich Internet applications.

As per the JavaScript analytics service Libscore, AngularJS is used on the websites of Wolfram Alpha, NBC, Walgreens, ABC News, and approximately 12,000 other sites out of 1 million tested in October 2016.

One of our recent engagements was a penetration test of a global FinTech 100 firm, which is a premier financial technology provider. Their clients includesome of the leading Online Brokerage firms, two of the top U.S. banks and multiple financial institutions. Their application uses Angularjs framework extensively.

The application used a fairly newer version of AngularJS, version 1.5.7 was found to be vulnerable to Client Side template injection with a bypass payload. In this application, the entry point for the attack was a custom “name” parameter which was found to be vulnerable to Persistent XSS. Leveraging this vulnerability, an attacker is able to inject Client Side Code into the application’s parameters and perform multiple attacks, including Session Hijacking, Malicious Redirect and other attacks.

We went ahead and crafted a client-side script which forwards the cookie details of the victim to a listener which we had setup on our server. We were able to obtain complete access to a Super Administrator’s account who had viewed the page containing the malicious script. We were able to perform and modify high value transactions from the super administrator’s profile in the application.

How did we identify the Vulnerability?

We noticed that the HTML page contained ‘ng-app’ in the view source of the page. This means that templates are used in the application, which will be rendered by AngularJS.

Angular expressions are sandboxed to limit the exposure of the DOM and maintain a proper separation of application responsibilities. In order to perform a successful exploit we need to break out of the sandbox and execute arbitrary JavaScript.

Angular templates contain expressions inside double curly braces such as ‘{{5-1}}’, which is a mathematical expression that would be evaluated and rendered as ‘4’.

To execute malicious JavaScript inside of the double curly brackets we need to escape the sandbox.

Bypassing the sand box in the early versions 1.0.1 – 1.1.5 was easy by using the following payload:


The payload used in this application to initiate the attack was:

{{x = {‘y’:”.constructor.prototype}; x[‘y’].charAt=[].join;$eval(‘x=alert(document.cookie)’);}}

In earlier versions until 1.1.5, it is also possible to perform XSS attacks by Bypassing the CSP, by injecting “ng-click=”$event.view.alert(1)” as the payload. This is possible as “$event” exposes “window” through “view”.

<h1 ng-click=”$event.view.alert(1)”>XSS!!</h1>

It is a known fact that most applications which use AngularJS, use the older versions. Multiple sites are still using the versions from 1.0.1 to 1.1.5. The migration to newer versions is often overlooked as it might be a laborious process; However, migration to newer version alone is not to be considered as an effective solution to mitigate expression injection.

The possible remediation for this vulnerability would be to avoid embedding user input dynamically into client-side templates. If that is not feasible, filtering of template expression syntax before embedding the input into client-side templates should be considered.

AngularJS expands the attack surface of an application significantly, hence developers need to know about the latest bypasses and build the necessary remediation in their applications.

The 3 Most “Resistant & Persistent” Application Security Vulnerabilities

My team tests at least 5 applications a week on average. We constantly work with Web Apps, Web Services, Mobile Apps and now, IoT driven applications, which have a pretty large web services layer supporting it. We work with multiple product engineering teams, especially developers, to help them fix those niggling security problems. Recently, I had a question that I wanted answered in substantive terms. “Which vulnerabilities are most resistant and persistent across all the apps that we test?” This is a pretty expansive question. We test scores of apps, that have a larger set of vulnerabilities. I was looking for application vulnerabilities that either haven’t been fixed over time or have been fixed at a given time, but have resurfaced elsewhere. These vulnerabilities, I would put into the “Resistant, Persistent” category. I loaded our sanitized vulnerability metadata onto an ElasticSearch Server. And armed with my python scripts for analytics and aggregation, I crunched some numbers and I have tried to drill down to the 3 Most Resistant Application Security Vulnerabilities, from January of 2015 to the present day.

Cross Site Scripting (XSS)

There’s nothing new about Cross Site Scripting. Its been a permanent fixture on the OWASP Top 10 as far back as I can remember. One would think that Cross Site Scripting (XSS) would have been fixed or at least marginalized by this point. However, unlike SQL Injection, Cross Site Scripting has continued to enjoy relevance and multiple leases of life. This is simply owing to the fact that the application attack surface has increased significantly with tons of third party Front-End JavaScript libraries, inconsistent output encoding, dependencies on CDNs, etc. Cross Site Scripting has proven to be a formidable vulnerability to fix. Nearly everly client we test seems to have atleast one or more significant Cross Site Scripting flaw. This, despite the fact that modern web frameworks come with “batteries-included” approaches to validation and output encoding. So, if you’re app is using any of the above elements that I just mentioned. You need to probably look for this highly resistant and persistent security flaw.

Insecure Direct Object Reference (IDOR)

Insecure Direct Object Reference really are Authorization Flaws. Using these flaws, an attacker can bypass permissions management controls and gain unauthorized access to sensitive information from other user accounts or other data  sets. The major manifestations of IDORs happen in two ways. One, (more uncommon) where the attacker is able to manipulate model data and gain access to privileged functionality . The other manifestation (more common) is one where attackers can identify primary key/identifier values and attempt to gain access to other user accounts or elevate privileges. The reasons for this vulnerability being “resistant and persistent” is due to the following factors:

  1. There’s a lot more impetus given to authentication than authorization in the design/architecture of an application. What’s worse is that authorization is a highly design centric activity that is usually done poorly. Its not granular enough, its not comprehensive enough and its coverage is inadequate. So, its doomed to fail.
  2. With Web Services (where’s there’s no UI Control) this is rampant because developers just don’t expect/realize that there are these bugs in the system.
  3. These vulnerabilities cannot be tested directly with Automated Vulnerability Scanning tools like AppScan, Burp, etc. They have to subjected to manual/scripted security testing with special impetus on authorization testing.
  4. The other (probably smaller) reason is that developers don’t design primary keys to be truly random. Some of them are basic incremental integers(1,2,3) or what they think is random(20160327001), which I am sure by now, you realize is anything but.

Direct Object Reference flaws can be deadly. They need to be understood and addressed the right way.

Cross Site Request Forgery (CSRF/XSRF)

Cross Site Request Forgery is really an attack against Authentication. In short, an attacker is making the user do things the user never intended to do on your application. This could be anything from forcibly changing the user’s password to adding an unauthorized rule on a firewall web console. Most of the web apps we test, CSRF is a common finding. The effects of a CSRF are only aggravated with XSS on the same application. To developers who think that CSRF only works on browser based web apps, think again. Web Services can equally be affected by CSRF Attacks.

Disclaimer: What I have written above, is in no way a comprehensive list of application vulnerabilities. These are just the 3 applications that my team and I are seeing more frequently than others in modern applications. These vulnerabilities happen to be both resistant and persistent because they seem to either stay unmitigated (for long periods of time)

This article was originally published on Abhay Bhargav’s LinkedIn page

3 Things to Make Your Application Security Suck Less!

All of us have problems. Some of them big and some small. Then there’s Application Security. In my discussions with technology heads of high-velocity application companies, they come up with a single problem. Application Security. “We can never seem to get ahead of the problem”, they say, wearily as they try to remediate findings from their latest penetration testing or vulnerability assessment report. Release cycles are delayed or heavily compromised, customers are unhappy over security flaws or you are constantly on edge about some hacker (or script kiddie) completely owning your application and putting your company on the headlines of the front page of next day’s news, and subsequently have “expert bloggers” like me writing articles like “5 Things you can learn from So and So breach” Let’s face it, your application security sucks! But don’t fret, there’s hope yet. In my opinion, there are 3 very critical things that organizations miss out on when trying to fix application security. This is not typically testing or secure coding or any other typical solutions that you would have come across. I am going to use stories to make my points. Here goes…

The $1 Hotel Room

We were recently testing a large and significant SaaS Solution that integrates with some of the biggest hotels and hotel chains in the world to give them easy online booking and customer relationship management solutions. They are a highly competent and technical team that has a good understanding of security. They were confident of their ability to have thwarted the OWASP Top 10 categories of flaws and were handing over their app to us for a penetration test. During the pentest we found that their web service was vulnerable to a integrity flaw, where we were able to bypass their checksum controls and manipulate booking amounts for hotel rooms. We were able to book a hotel room that was worth $650 for $1. Needless to say, they were shocked and admitted that they needed some time to fix this flaw. During my discussions with their VP of Engineering, I asked him why they had missed an obvious flaw like that. He said that they had looked at flaws like SQL Injection, Cross Site Scripting and what was considered “typical OWASP Top 10” flaws and had focused on the controls and counter-measures to address that.

This “Control-driven” Application Security culture is quite rampant. Companies use “lists” like the OWASP Top 10 and SANS Top 25 to dilute and create a bunch of security countermeasures that would address the vulnerabilities expounded in these lists. They completely miss out on business logic flaws and business-focused flaws because they don’t think “Threat First”. I have personally seen and implemented Threat Modeling Frameworks for organizations that has delivered amazing results as these companies were forced to think “Threat First”. This form of thinking gets you to analyze and detail some of your most critical threats in both business and technology terms and come up with high quality counter measures. In addition, these can be used as “security test cases” to perform detailed security testing for these Threat Models.

There are many ways to model and inculcate a “Threat First” thinking, including Threat Modeling, Table Top Simulations, etc.

Me and my Dependents

During a pentest for a major cloud application company recently, we identified a pretty serious authentication and session management flaw. For some reason they were failing to invalidate their Auth Token and their web service could be spoofed quite easily, if an attacker figured out the steps to do so. Turns out that the PaaS platform that they were using had a flawed token expiration call that didn’t really invalidated the Auth Token, rendering the application vulnerable to spoofing and similar attacks. Then, in the same pentest, we found a serious flaw in their Crypto library as well. In an age of modular applications rife with large number of dependencies with their own set of dependencies, this is becoming the biggest problem that tech teams have to deal with. Security flaws in underlying libraries, server components (in an ever increasing stack) and other executables are causing much pain to technology teams.

Unfortunately, there aren’t many great ways of addressing this other than certain customized solutions. We were shocked when we found that vulnerabilities in one client environment were cut by 65% when we implemented a security dependency management solution that we had developed for them. It became an integral part of their CI/CD process. Either way, the first way to tame the problem is to make an inventory and constantly update the inventory based on changes to the application. Luckily package managers and build tools provide functionality to extract and store this information for use. Once this is done, manual or automated investigative techniques must be used to identify and actively remediate security threats from dependencies.

“We have a tool”

I am in awe of marketing departments at some of these security companies. They make it sound like their product can find anything from SQL Injections to a needle in a 1 ton haystack. Their products are sold as a panacea to InfoSec and AppSec teams that are looking to solve their security problems with one or more of these tools. Unfortunately, these tools can’t find crypto bugs, business logic bugs, authorization bugs, authentication bugs, advanced SQLi bugs, Advanced XSS bugs, and mostly bugs with web services or slightly complex RIA frameworks. See where I am going with this? Tools are great, we all use them. I use them a lot, but I also understand that each app is different and tools can only help you with low-lying security flaws and point you in the right direction. Missing out on Manual testing or scripted manual testing is like missing out on the main course at the buffet. You’re going to remain hungry while someone else has your food. A very revealing statistic was when we integrated manual security testing into the CI/CD pipeline of one of our largest clients and they were able to identify and eliminate 100% of their critical and high vulnerabilities even before it went to Staging. Believe me when I say that there’s no better way to test an app as with a combination of manual and automated, that a purely automated tool can’t even come close to uncovering.


This article was originally published on the author’s LinkedIn page.