When writing a AWS lambda function, we need to be careful about secure coding issues.
If your lambda function takes an input and use it to run a command, you need to avoid using os.system(...). You should use subprocess.run(...) but without the shell. The commands provided to subprocess should be in arguments.
Explaining the injection
I will use an example of AWS Lambda function that takes an input from event and uses it in a subprocess to run a command. Notice the command is used in a f-string.
We should refactor the vulnerable code by adding two defences:
Dependings on the context, try to whitelist the allowed characters.
If you do not know in advanced then it is crucial that you follow the next defence of using arguments command for subprocess.
Usage of arguments in subprocess
Instead of providing the commands in concatenated string or string format, provide an argument format ['touch', file_name]. This means you need to break down the command in different `subprocess` calls. You cannot run the multiple commands in one single subprocess.
One common routine is that you need to run a sequence of command at a specific same directory. With the use of cwd argument in subprocess.run(...), you can specify where the command should be executed.
Information Security is a broad field with many specialties such as Infrastructure Security, Cloud Security, Container Security. DevOps automation and Application Security (Source Code / Design level) etc. In real life context, an Application Security may need to focus on a few specialties since modern applications are using Cloud PaaS / IaaS and Containers.
Since there are so many specialties to learn, you may get overwhelmed by the knowledge and how to apply what you learn on the actual context. I read an interesting Div0 post on a cybersecurity career discussion panel on this topic:
Many aspiring cybersecurity practitioners say they are passionate about cybersecurity. But they have no work to show/prove their passion. Don’t just say you are passionate. Do it, show it!
There’s no shortage of aspiring cybersecurity practitioners who want to learn. However, there’s a lack of drive on how they can contribute to the organization. Continuous learning in a fast-moving industry like cybersecurity is important. However, you should also focus on how you can apply your skills (emphasis mine).
Cybersecurity is not just about technical skills. In fact, picking up technical skills is the easy bit. Shaping your attitude and mindset in how you deliver the promise your clients entrusted in you plays a much bigger role.
An essential characteristic to have in the industry is Grit — the passion and sustained persistence towards long-term achievement.
In a wide discipline like cybersecurity, it is important to collaborate and bounce ideas with fellow practitioners — that’s how you push the boundary.
The mad rush to get all the fancy certifications is not healthy. There’s no point being certified but you still can’t get a complete grasp on security controls or even the fundamentals. Focus on building up your skillset, not the alphabets behind your name.
Often Application Security new joiners have to learn development skills on their own projects if they are not joining from development background. They may be pentesters, sysadmin, DevOps engineers or career changers coming from another field. Each of them have their own unique perspectives.
You need to understand development but…
If you see in many Application Security job descriptions, many companies require development background. This requirement ensures that you can empathize with the development team that you will be working closely with.
Be careful not to become too developer-like because you will lose independent assessment since you are too close to the development team. For example, some developer tells you that this SQL injection is not a risk since the string values come from hardcoded config file. If you get too close to dev team, you might accept the risk without pointing out additional caution.
However, from another independent perspective, this means that SQL injection can happen if a rogue developer / QA / devops change the config file to a SQLi payload. The long-term solution is actually to use parameterized query and prepared statement even though the values are hardcoded. However if you get too close to dev team, you will start to feel their pain and deadlines if the feature is not released on time. So you might not even suggest the team to pick a more secure approach. Or you might ask the team to add this suggestion to backlog. It remains to be seen whether the safer approach will be adopted since there is always another new feature to complete.
Security Champions might also struggle to give independent assessment especially since they are part of the dev team. Moreover, many of them are developers or QA and have deadline and user stories to complete as well. Therefore Security Champions cannot do it alone and need pairing with the internal Security SME to give a balanced assessment.
On the other hand, you are too far from the development team, you will start suggesting crazy security activities from some PDFs or slides that will never gain any traction with the development team. Many good ideas sound great in powerpoint slides but difficult to gain traction in practice because real world has more decision-making factors in which security is just one of them. You need to at least understand some of these major factors such as business risk appetite, ROI, regulatory requirements etc.
Not enough to learn Development
To understand Application Security in depth, the newbies have to pick up coding and software development concepts such as MVC etc. on their side projects or on the job. It will take time and requires a lot of experimentation, readings, note-taking and questioning.
You shouldn’t just learn coding like watching a Udemy course on Web Development or Mobile Development. After all, your job also consist of the security aspects of delivery. Most of the development courses will not mention Application security topics. This means that you need to create your own contexts to apply every topics that you have watched on Application Security.
An example of I apply newly learned security knowledge to coding
Recently, I attended an online webinar on building secure React applications. This is an informative talk with hands-on examples that I recommend people to watch.
My first thought is to find the React code that I wrote on my own.
Previously, my understanding was that ReactJS is secure by default library and XSS is difficult to achieve unless developer use dangerouslySetInnerHTML. But from the video, I updated my understanding of ReactJS and recognized more XSS attack surface.
Then I tried to modify my React component code to create the XSS vulnerability. Imagine the developer thinks that getting the name from props is safe to use in href.
From now, when I look at ReactJS code, I will also include such checks in my code review methodology. Or when I am looking at ReactJS app, I will be more awareness of more things to look out for such as hrefand srctags etc.
Before performing source code review, you should get some hands-on experience with developing an iOS application. In this post, I will show you some of the possible steps to get started. You will spend roughly 30 hours on developing some iOS applications and learning some of the common libraries in Swift 5.
Now it is time to write some code. The purpose of this exercise is to understand the basic structure of an iOS application such as: – Learn how to link UI objects (e.g. UIImage, Buttons, Sliders etc.) in the Main Board to the View Controller – Learn how the function in the ViewController can update the UI objects values. – Naming UI objects – Uploading images into Assets.xcassets directory – Learn to initialise variables in Swift. – Differentiate between ‘var’ and ‘let’ declaration (var is used to initialise the mutables while let is used for declaring constant)
Build an intermediate iOS application – 8 hours
Build an application which stores data locally. The types of data should also include sensitive data such as username and password.
Purpose of UserDefaults. The data is saved as plist. This is not a database. Just use it to learn small kb of data and not for large amount of data.
Data Storage Methods: 1. UserDefaults 2. Encode Data into plists 3. Keychain (An API to store sensitive data (e.g. username, password etc.) securely 4. SQLite 5. Core Data (Object Oriented Database) 6. Realm
Build another intermediate iOS application – 12 hours
<Draft version> The purpose of this blog series is to help an Application Security engineer to learn enough about iOS application security in order to perform source code review. The posts will also require hands-on testing as this will increase understanding of the vulnerabilities.
iOS Application Security
iOS Hacker’s Handbook
Advanced Apple Debugging & Reverse Engineering
Mac OS X and iOS Internals
Volume I: User Mode (v1.3)
Volume II: Kernel Mode
Volume III: Security & Insecurity
The Mobile Application Hacker’s Handbook
OWASP Mobile Application Security Verification Standards (MASVS)