I have assisted this week to a technical event called Devoxx and have tried to learn as much as possible about security because it is the area in which I have to improve most. I will summarise what I have learnt as many of you may also be interested in it.
More responsibility on developers
Security has usually been checked by specialised teams and developers just did basic checks to prevent SQL injections or sanitise the content of the forms. Now we have to be more involved because companies are releasing faster to production (even multiple times per day) and the security team cannot cope with that rithm. We should also improve the communication with them so they know which features have more risk and companies like Slack have forms to asses about it.
New targets for hackers
They used to attack big companies to get recognition or ask for money but they are starting to target any kind of organisation. They are trying to hack servers to use their resources to get money mining cripto-currencies, so we have to increase our efforts to harden the servers. They are also attacking serverless applications so we should set billing alarms as they are paid by usage.
Be careful with dependencies
Many applications have good code but they use dependencies that may have been compromised and allow attackers to get even the credentials of AWS. We have to check them even when the code is used by a serverless function. There are some tools like Snyk that analyse dependencies automatically and it is recommended to use NPM shrinkwrap so the new versions of the npm dependencies are not downloaded automatically as they may have vulnerabilities.
Automate the security analysis
We can write BDD tests that check security using tools like Gauntlt, we can use ZAP in combination with Selenium as part of the regression tests and there are SAST and DAST tools to analyse of the code. There are also new penetration testing tools like SQL Map that detects SQL injections and specific tools for certain services of Amazon like subbrute, sublist3r or bucket-stream that check S3 buckets.
Encryption everywhere
Most organisations encrypt the data when they save it in the database but don’t add security between the microservices because they are in a private subnet. This is not enough because the data flows unencrypted and may be obtained by a compromised serverless function for example. Most of the AWS services also offer server side encryption so we just have to configure them properly.
Understand the code we write
Many security libraries have both secure and insecure methods. It is important to look to the documentation to be sure that we use the right ones. We should also understand what the code is doing and the parameters that should be used to ensure that they are safe enough.
New ways to work with cookies
There are ways to use cookies in a more secure way to prevent XSS, XSRF… attacks, e.g. using the HttpOnly or SameSute attributes. These changes are still not supported by all the browsers but there are workarounds to support them.
Resources for developers
Security texts are quite complex and more focused on how to attack that on how to code to prevent it. If you want to learn more and don’t know where to start, you can look to ASVS, try some rules and add more incrementally. There are some pages to learn like Security Shepherd or Web Goat and there is this section in StackOverflow about security.
Summary
We should start learning about security the same way as we learn about new technologies or architecture. It takes time and seems daunting at the beginning but there are resources to start step by step and new tools that allow to automate the checks.
Consultant and security champion specialised in Java, with experience in architecture and team management in both startups and big corporations.
Disclaimer: the posts are based on my own experience and may not reflect the views of my current or any previous employer
