It’s time to talk about serious stuff… The world is becoming more and more digital and the amount of data moving through the internet increases every single day. From time to time certain groups of hackers carry out attacks on large companies in order to steal information, which they then use to ask for “ransoms” or sell it to third parties for a large amount of money (or crypto-currencies).
No matter what kind of project you are developing, the task of any developer should be to produce readable, maintainable, and above all secure code.
Secure by design
One of the most common mistakes in software development projects is to leave the security aspects to the last minute. For example, a very common practice is to start developing the necessary requirements and once they are finished, perform penetration tests just before moving to the production environment and that’s it.
Security must be taken into account from the design phases of the application, identifying which are the weak points that need more attention, and taking action during all phases of the project life cycle.
A “safe system” must comply with the CIA-Triad:
- Confidentiality: Information must not be made available or disclosed to unauthorized entities
- Integrity: Is the property of safeguarding the accuracy and completeness of attacks.
- Availablity: Is the property of being accessible and usable upon demand by an authorized entity
In addition, secure design assumes that exploitation of threats is taken for granted. In addition, it establishes the following principles:
- Least privilege: Every user or module is given the least amount of privileges necessary
- Defense in depth: Do not rely on a single measure to keep attackers out
- Fail securely: If your system fails, fail securely and do not expose more information than needed in stacktraces or logs.
- Detect and record: Your system must be able to detect unusual events and record them.
- No security by obscurity: You cannot rely on being obscure to be secure. Assume you have an open design, your software must be secure even if attackers know the whole architecture.
- Don’t trust: Assume that everybody want to damage your system
- Keep it simple: Implementing more than what has been specified opens up space for new vulnerabilities. Minimize the attack surface
Defensive coding
An experienced programmer knows what countermeasures need to be applied when developing certain functionalities to prevent software from containing vulnerabilities.
- Know your apis: Using an API or library in the wrong context may result in vulnerabilities. Copying internet examples without fully understanding is a mistake!
- Attack surface: Any input is a possible entry point for attackers. Do not increase the attack surface beyond what is needed to implement the required feature!
- Complexity: You can not secure what you don’t understand!
However, it is not always easy to detect this, which is why it is very important to have your code reviewed by other developers. Thank god, in some cases it is possible to automate the code analysis by using tools like Spotbugs.
It should also be taken into account that projects usually contain third-party libraries to which we do not have access and may nevertheless contain vulnerabilities. This is why there are certain tools that perform a static analysis of the code (SAST), as well as the libraries imported into our project..
Security testing
SAST (Static Application Security Testing)
SAST tools are a set of technologies designed to analyze the application source code, byte code an binaries for coding and design conditions that are indicative of security vulnerabilities.
These tools analyze applications from the “inside out” in a non-running state (white box)
- Many errors can be found
- Precise feedback (line of code of the error highlighted)
- Errors can be found on early stages of the SDLC
- Some security problems are hard to find statically
- Often high amount of false positives
DAST (Dynamic Application Security Testing)
Designed to test and detect conditions indicative of a security vulnerability in an application in its running state (black box). Most DAST solutions test only the exposed HTTP and HTML interfaces of WebApps, however some solutions are designed specifically for non-web protocols
- Can find semantical errors
- Environment misconfigurations
- Represents the «hacker» approach
- Needs a running application
- Resource heavy
IAST (Interactive Application Security Testing)
IAST tools work in a different way than static or dynamic tools. They leverage information from inside the running application, including runtime requests, data flow, libraries and connections to find vulnerabilities accurely (grey box).
Establish a mitigation plan
The CVSS (Common Vulnerability Scoring System) is a rating method for vulnerabilities that asseses their severity using 3 groups of metrics:
- Base metrics: How difficult is it to exploit the vulnerability? How are the CIA properties affected?
- Temporal metrics: Is there an exploit already? Has the vulnerability been patched since?
- Environmental metrics: How does the vulnerability effect your specific environment?
When vulnerabilities show up, it is recommended to establish an action plan and this is a very good start point. We should rank vulnerabilities in order to decide “when” and “how” they have to be mitigated.
OWASP
The Open Web Application Security Project is a non-profit organization that aims to educate developers about software security.
The OWASP recommends the use of techniques such as manual inspections and reviews of people and processes, threat modelling, manual and automatic code reviews and penetration testing.
These start at different points of the SDLC (Software Development Lifecycle) and can intercept development errors with regard of software security at an early stage.
To make developers life a bit easier, there is a tool named OWASP Dependency check, which attempts to detect publicly disclosed vulnerabilities contained within projects dependencies. It does it by determining if there is a CPE (Common Platforma Enumeration) identifier for a given dependency. If found, it will generate a report linking to the associated CVE (Common Vulnerabilities and Exposures) entries.
Summary
I hope this help you to understand better some security aspects and how developers should think before starting to write code.
There are some tools that can be easily integrated in our projects to perform static analisys or dependency check (I mentioned this already), everything automated through pipelines. If you want me to write a post to show you how to use these tools, leave me a message and I’ll be happy to do it!
Cheers!
