Application Security for builders and creators — part 2
Application Security for builders and creators — part 2
Previously on Application Security for builders and creators — Alice and Bob wanted to build a vaccine passport app with go micro-services and a React UI. Claire suggests the team to engineer security into their app with ShiftLeft.
Review with AppSec on Zoom
“Claire, let’s jump right in to the topic for today,” said Bob as he hurriedly looked for the screen-sharing button to share the ShiftLeft dashboard UI with Alice and Claire on Zoom.
“What do you mean my git branch has 20 SQL Injection and 6 XSS vulnerabilities?” queried Bob. Before Claire could unmute herself, Bob continued, “For Sensitive Data Leaks I’m logging the payload in dev which I can turn off when the app goes live. As you might know we are planning to use docker and host the micro-services on Google Kubernetes Engine (GKE). All our CDN endpoints are behind Cloudbare WAF. Should we still treat these SQLi findings as critical?”
Claire started with the usual icebreaker, “Can you hear me?”.
She added, “It’s a strong argument Bob. Thank you for sharing the details on the application infrastructure for your app. But unfortunately, docker or GKE while being excellent virtualization and orchestration technology, cannot protect an application against SQL injection or any application-specific vulnerabilities”.
Showing empathy and emotional intelligence are quite key while discussing security topics with developers. Instead of blaming Bob or making fun of his work, Claire started the conversation by thanking Bob.
“Yeah, you are right, Claire!” declared Bob. “But surely that expensive WAF can stop the injection attacks, right?”
Claire continued, “Ideally yes! But recently, we had an issue with Tracey’s apps. They suddenly stopped working so as a workaround we run our Cloudbare WAF in monitor-only mode in production”.
“WHAT!!!” Alice and Bob screamed spontaneously.
“Why are you feeling shocked? It is quite common to run WAF and other runtime security tools in monitor-only mode. The idea is that over time every one would feel confident to let the security tool to block malicious traffic and payload automatically. But that may never happen soon enough since the risk of losing a legitimate traffic and business usually outweighs missing an occasional malicious traffic,” concluded Claire.
There was silence even though everyone were clearly unmuted. The team learnt the hard reality of those cloud infrastructure security tools — they run in monitor-mode and produce alerts that someone else has to review periodically. The person reviewing the alerts, usually from a SOC team, may not have the necessary engineering or even security experience to differentiate a malicious injection attempt from a genuine API request with JSON or gRPC payload.
Threat modelling for busy developers
Bob is a polyglot developer who has recently been juggling with go and TypeScript. He is also involved with configuring Helm charts and ensuring the Kubernetes namespaces on Google Cloud are optimized for zero downtime deployments and even canary deployments.
When a developer is this busy, expecting them to think about the Threat Modelling and those textbook recommended STRIDE and other frameworks is ambitious. Offering security training to busy developers in the form of a learning academy is a good idea. Claire decided to help the team by opting to author Threat scenarios in gherkin language which developers could readily understand. Some example scenarios are below:
As a user of passport api
When I change the id in the request
Then I should not be allowed to view other user's data
As a user of passport api
When I change the folder name used for the bucket
Then I should not be allowed to download other user's files
As a user of passport UI
When I use a different email instead of mine
Then I should not be allowed to reset the password for other users
By collaboratively authoring threat scenarios, busy developers like Bob understood the importance of including security elements in the code instead of entirely relying on external infrastructure such as Kubernetes or WAF to secure their application. Scenarios combined with a diagram helps them to visualize the threat blast radius and understand the roles and responsibilities of developers, AppSec and SOC teams — Security is a shared responsibility after all.
Bob agreed to review the findings on ShiftLeft and incorporate additional checks based on the threat scenarios. Claire meanwhile, configured ShiftLeft analysis to lower the severity of Sensitive Data Leaks category to Info by using modify-findings CLI command as explained here.
Developer experience with ShiftLeft
As Bob started playing with ShiftLeft, he realized that ShiftLeft NG SAST is not a bad tool after all. As he navigated to the SQL Injection category, he saw that ShiftLeft was presenting the entire vulnerable data flow as evidence.
The source of the SQL Injection were either the http middleware or the user’s cookie. The sink in case of an SQL Injection is the database library code that was interacting with the database which could be both Relational or NoSQL (Aka. NoSQL Injection). Bob had not thought about validating or sanitizing the user inputs while working under pressure.
By presenting, the file and method information ShiftLeft helped Bob to resolve all the SQL Injection vulnerabilities on the same day itself!
Shifting-Left improves dev productivity
By pointing out application vulnerabilities in a specific branch, ShiftLeft NG SAST helped Bob not only to address the current set of findings but also gave him an idea to build new endpoints that will not generate any SQL Injection vulnerabilities in the future. After all, once a common validation or sanitization method is developed every endpoint that gets the user input could reuse the same methods or even the middleware. Bob even published his validation methods as a common library to help other teams in their organization. Well done!
After remediating the SQL Injection vulnerabilities, Bob and Alice turned their attention to Cross-Site scripting (XSS). Using the React framework for the UI was after all Alice’s idea; the documentation page on React claims that the framework automatically sanitizes user input reducing the opportunities for XSS. Yet, here ShiftLeft is claiming that there are 6 XSS vulnerabilities in the app. How is this possible? Whom do you trust — ShiftLeft the Application Security expert or React documentation from Facebook?
The team decides to have another call with Claire, their DevSecOps person, to discuss XSS vulnerabilities.
To be continued in part 3 …
Application Security for builders and creators — part 2 was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Prabhu Subramanian. Read the original post at: https://blog.shiftleft.io/application-security-for-builders-and-creators-part-2-47cfc6cd7326?source=rss----86a4f941c7da---4