Fixing Insecure Code One Developer At A Time

When she moved from coding into security, Tanya Janca just couldn’t bring herself to leave software development alone. That’s a good thing for the rest of us.

When she found cross-site scripting (XSS) problems cropping up in one developer’s code, she asked if it would be ok to come spend some time with him at his desk. She politely taught him the joys of input scripting and whitelists, redoing his code with him as she walked him through an XSS cheat sheet. By the time she’d finished, he was a convert to secure coding.  

One down, several hundred thousand to go.

Janca started out as a developer over a decade ago before moving into a security role. These days she’s a senior cloud advocate for Microsoft. She spends her time talking at conferences and advocating both for and to developers.

Getting people to code more securely is more than just a professional platform; it also seems to be her mission in life. The OWASP chapter leader is so passionate about it that she’ll be teaching people the importance of it in her talk at the SecTor conference this year.

Decades after the first software program was written, insecure code is an endemic problem in modern software development. Secunia, a vulnerability research team owned by software marketplace Flexera, discovered nearly 20,000 in 2017 – double the number discovered five years prior.

We see software flaws leading to some blockbuster data breaches, such as Experian’s 2017 hack, caused by a bug in Apache Struts. Sure, they could avoid such breaches by patching properly, but ideally the developers wouldn’t let the bugs into the software in the first place.

The causes of poor software security

The biggest problem for developers starts in the education system where the focus is on productivity, not protection, warns Janca. “In their diploma or degree they get perhaps one class on security. Can you imagine if we just gave electricians a single safety class at the end?”

The problem continues in many companies where security isn’t taken seriously either. Microsoft is security obsessed, she says – it has followed its own secure development lifecycle (SDLC) program for over a decade – but elsewhere, developers are given tight deadlines and little support. “They are often not allowed security tools,” she says. “At a lot of the places I work, the first thing I do is teach developers how to use OWASP ZAP.”

This lack of management attention feeds into one of Janca’s pet hates: poor security culture. This is what she’ll be covering in her talk. It’s time to address the friction between security teams and developers, she says. “I used to refer to security teams as Doctor No.” They would always tell developers they couldn’t do something, but wouldn’t explain why.

Companies must work on culture change, she says. Devoting time to security training is a big part of that (make it cool, she adds, by showing developers how you can break into their apps). Complement it with metrics gained by feeding test results into a tool like DefectDojo. This surfaces patterns in software bugs that will get developers working to fix them.

She did this with one development team, hosting a lunch and learn and showing them the high number of XSS bugs in some of their apps. It inspired the developers to pore over their legacy code, which they found riddled with XSS flaws. ”We put them in our bug tracker and next week is XSS week!” said one developer, vowing to eradicate the bugs. “Then we’re going to challenge you to find more!”

The changing face of security flaws

Janca’s enthusiasm stops things looking quite so bleak and highlights a way forward. Another promising development is the hardening of common frameworks and libraries to prevent some of the most common vulnerabilities from the past.

Five years ago, cross-site request forgery (CSRF) bugs were everywhere. Today, frameworks like .Net and Python’s Django carry built-in protections. That helps raise the bug bar, she says.

“My data’s for sale on the dark web but I don’t know why! I don’t know how it happened but I know it’s bad!”

The results are showing up in the OWASP’s famous top ten vulnerability list, which highlights the bug categories showing up in software. This bug list was traditionally released every three years, although the organization skipped a year last time around, updating it in 2017.

CSRF has now slipped from the top ten to number 13, she points out. Now, though, newer mistakes in software are emerging. She highlights XML external entities (XXE), in which attackers inject hostile content into XML documents to exploit XML processors. Another, insecure deserialization, happens when programmers deserialize objects from untrusted sources. That’s difficult to exploit, but devastating if an attacker can use it.

Another insecurity she sees in software is insufficient logging and monitoring. Developers are often tempted to skip building logging code into their apps. It’s hardly the fun part of software development, after all. But without it, security teams will have a tough time detecting a security problem, she warns.

“Incident responders are totally screwed,” she says, outlining a bone chilling scenario: “My data’s for sale on the dark web but I don’t know why! I don’t know how it happened but I know it’s bad!”

You can catch Janca at the October 1 2018 Toronto OWASP Meetup before seeing her talk at the SecTor conference. Don’t forget to catch her OWASP DevSlop YouTube channel, where she explains how to fold security into software development.