How To Secure Your Web Application (Part 2) – Handling common security vulnerabilities

If you’ve read the first blog post of this series, you already know the basic overview of how this journey will look. Now it’s time to steer this journey towards the security aspect of web application development.

First, let’s set the stage by understanding some common security threats for a web application.

OWASP Top 10

The OWASP Top 10 is a list of the most critical security risks to web applications. It’s globally recognized by developers as the first step towards more secure coding.

The OWASP Top 10,

1. Injection

2. Broken Authentication

3. Sensitive Data Exposure

4. XML External Entities (XXE)

5. Broken Access Control

6. Security Misconfiguration

7. Cross-Site Scripting (XSS)

8. Insecure Deserialization

9. Using Components with Known Vulnerabilities

10. Insufficient Logging and Monitoring

These OWASP Top 10 sounds menacing, isn’t it? No, worries. If you follow along with me, you’ll know exactly how to implement mechanisms that will surely stand guard against these threats.

One such measure is using Spring Security.

Spring Security

Add Spring Security dependency to your Spring Boot application’s pom.xml as follows.

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-security</artifactId>
</dependency>

We can handle the security using Spring Security by Creating a custom configuration class extending WebSecurityConfigurerAdapter and then overriding the methods to customize security settings for HTTP requests and authentication.

Mitigating SQL injection

1. Using Prepared Statements

We are using Spring Data JPA which offers support for parameterized queries, preventing direct injection of SQL code.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>

Spring Data JPA facilitates the creation of parameterized queries automatically from method names or @Query annotations.

2. Leveraging ORM capabilities of JPA

JPA, in conjunction with Hibernate, provides Object-Relational Mapping capabilities. This maps Entities and their relationships to database tables, allowing developers to work with Java objects rather than direct SQL statements.

@Entity
@Table(name = "vehicle_service")
public class Booking {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "booking_id", nullable = false)
    private Long id;
 
    @Column(name = "date")
    private Date date;

Mitigating Cross-Site Scripting (XSS)

We do this by using the Thymeleaf library which automatically escapes HTML characters safeguarding against XSS attacks. Add the following dependencies to your pom.xml.

<dependency>
    <groupId>org.thymeleaf.extras</groupId>
    <artifactId>thymeleaf-extras-java8time</artifactId>
</dependency>
 
<dependency>
    <groupId>org.thymeleaf.extras</groupId>
    <artifactId>thymeleaf-extras-springsecurity5</artifactId>
</dependency>

e.g., When using th:text, Thymeleaf automatically escapes special characters in the text.

Mitigating Insecure Direct Object References (IDOR)

– Avoidance of exposing direct object references such as database IDs in URLs or parameters. Instead, we use tokens or identifiers that are not easily guessable.

– Utilization of secure session management techniques and tokens that are validated on the server side to control access to resources.

Mitigating Cross-Site Request Forgery vulnerabilities (CSRF)

1. Spring Security Configuration

Configure Spring Security to enable CSRF protection by adding the CSRF filter in the security configuration file.

2. CSRF tokens

We can utilize Spring Security’s CSRF protection by including CSRF tokens in forms and verifying them during form submissions and Thymeleaf’s th:action attribute to generate form action URLs, ensuring they are protected by CSRF tokens.

The mitigation of threats such as broken authentication, session management and sensitive data exposure will be mostly handled when we integrate an IDP, which will be covered in the next article of this series.

Now that most of the basics of security are covered, the seatbelts are tight and we feel safe through the journey. But, are we safe as long as anyone and everyone enters our vehicle? Of course not! Just as we wouldn’t let just anyone hop into our car, ensuring the right individuals access our application is extremely important. This is where the integration of an Identity Provider (IDP) comes into play. And we will peek into this in the next article.

If you want to take a look at the full project, it’s available here in this GitHub repository.

With much love,