Breaking News

National Coding Week: Application Security Shortcomings and Solutions

There is no 100 percent secure, completely flawless computer program, yet security practices are often an after thought in programming. But even with the best security practices ‘baked into’ the software life cycle (SLC), there is still the possibility of a zero-day vulnerability existing in the code. So, given the adage “the best defense is a good offense,” the importance of securing code from inception to production cannot be overstated.

Now you may be wondering– who is responsible for ensuring secure code is written– the education system, individual programmers, companies, or the government? And what measures can organizations take to reduce software vulnerabilities?

 In general, academia focuses on computer theory and is less concerned with feasibility. Plus, due to the official accreditation process, the development of new technology programs is slow. More importantly, students learning programming languages in schools should be taught about the logic flaws inherent to those languages. In the case of JavaScript, programmers can exploit how the language is interpreted and coerce alternate outcomes like ‘truthy’ or ‘falsy.’ Although schools may introduce students to search query language (SQL) vulnerabilities, the threat landscape is ever-evolving, and universities struggle to keep up.

 In the workforce, programmers focus on functionality, scope, and deadlines. Management of large programming projects usually involves intense compartmentalization so that developers are given specific, small tasks set by a scope. With the marketplace demands for the latest and greatest, programmers working under a deadline often rely on third-party private and open source libraries. Further concerns arise from who is responsible for ensuring the security and updating unpatched libraries. So, with a lack of context sensitive validation and scopes without security requirements, even more coding vulnerabilities can be introduced from unsecure, unpatched libraries.

To offer a real-world example, it only took criminals 22 lines of JavaScript to initialize the scam of 380,000 British Airways accounts. Not only did this affect the consumers, the British Airways company now faces up to £500 million ($650 million) in fines under the GDPR. In the grand scheme of coding programs, 22 lines of code is just a drop in the bucket. But it’s not about the amount of code. It’s about executing powerful commands to exfiltrate data. Surprisingly, most successful hacks are in 5 lines of code or less.

Here is an example of a SQL query written so that both username and password credential verifications are by passed.

Executed user input for username is ‘ or ‘1’=’1and password is ‘ or ‘1’=’1

The above statement actually queries for all the users in the database, and thus, bypasses the security. Within one simple line, this not only plays with the logic of how computers interpret zero and one, it violates the trust boundary between what is considered data and code.

Computer knowledge gained at University can already be out of date by the time students graduate. But more importantly, education should not be a goal in and of itself, rather, education should prepare for actual workforce demands.

That is why WhiteHat Security offers several solutions to the security challenges that developers face. Our award-winning Application Security Platform is empowering true DevSecOps by continuously assessing the risk for organizations’ software assets and helping them to embed security throughout–and beyond– the SLC.

The following resources are a great place to start.

  1. Three-part crash course and full course on secure coding for developers: https://www.whitehatsec.com/wp-content/uploads/2017/04/appsec-traning-program-solution-brief.pdf

               2. Secure DevOps whitepaper: https://www.whitehatsec.com/resources-category/premium-content/design-secure-software/