Software security is becoming crucial nowadays, as the world is becoming more and more dependent on software. Bárbara Vieira and Theodoor Scholte are talking at Voxxed Days Athens about software security: we asked them what to watch out for.

 

What are the most common security pitfalls when developing a web application?

Although the world is becoming more and more aware of software security, there are still a lot of mistakes and misconceptions around information security. Most in the software industry believe that having an application that performs some sort of authentication and access control, and uses a secure connection is enough to protect the data from intruders. However, in most of the cases access control is not properly implemented. For example it doesn’t scale, doesn’t protect all the data or all the system functions, etc. This leads to a cascade of other vulnerabilities.

At SIG, we have extensive experience in conducting secure code reviews and developing secure applications. In this talk, we will address the typical security pitfalls in modern web applications. We will explain how software developers can prevent them during the development lifecycle.

How do you build in security to the software development lifecycle?

The problem of having insecure and faulty systems lies on the lack of a correct definition security requirements. Most of the time, security requirements are overlooked. Security is implemented as an overlay. Security by design is rarely implemented. A secure development process is rarely followed. The lack of risk assessment and attack surface analysis of the application leads to a lot vulnerabilities. This is mostly because mitigation of the risks is not performed earlier in the development phase, and countermeasures never get to be implemented. Security must be addressed in the early phase of the software development process.

Are there any frameworks that you recommend to help address security pitfalls?

Most frameworks, such as .NET and Spring Boot, already provide a lot of countermeasures to prevent some of, for instance, OWASP TOP 10 vulnerabilities. The main problem when implementing security countermeasures is twofold:

  1. Security is a very complicated concept to grasp (even when developers are trained).
  2. Some of these frameworks are poorly documented and have insecure defaults.

This combination makes it hard to prevent vulnerabilities, even when relying on frameworks that help address the security pitfalls.

Should developers rely on the frameworks, or do they need to actively test and investigate their own applications for security pitfalls?

Information security is more than just coding and implementing countermeasures in the software systems. Physical security of the devices hosting the applications, for instance, is equally important. Therefore, relying on frameworks to address the security issues in the applications always leads to vulnerable applications. Applications are always different and always have different business requirements. This leads to different attack surfaces. Most of the time, implementation of countermeasures is business specific. Thus they require testing and reviewing all the risks, requirements and threats. Implementation of every new business requirements may lead to a new threat, so it’s always necessary to test if the previously implemented countermeasures still hold. Summing up, testing is the only way to validate that the initially defined security requirements are met.

 

For more, see Bárbara Vieira and Theodoor Scholte‘s talk:

Parthenon at night on Acropolis at Athens Greece

Security Challenges with Novel Web Apps

Profile photo of Katharine
About The Author
- Katharine is a Java developer by trade, turned Community & Content Manager for Voxxed. Helping developers learn and share knowledge. Contact me at kbe@voxxed.com with any news, articles or tutorials.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>