Why should Java API developers think about Cyber security?

Types of XSS attacks:

Reflected cross-site scripting :  Reflected cross-site scripting (or XSS) arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way. 

Suppose a website has a search function which receives the user-supplied search term in a URL parameter:

https://insecure-website.com/search?term=gift

The application echoes the supplied search term in the response to this URL:

<p>You searched for: gift</p>

Assuming the application doesn’t perform any other processing of the data, an attacker can construct an attack like this:

https://insecure-website.com/search?term=%3Cscript%3E/*+Bad+stuff+here...+*/%3C/script%3E

This URL results in the following response:

<p>You searched for: <script>/* Bad stuff here... */</script></p>

If another user of the application requests the attacker’s URL, then the script supplied by the attacker will execute in the victim user’s browser, in the context of their session with the application.

There are many different varieties of reflected cross-site scripting. The location of the reflected data within the application’s response determines what type of payload is required to exploit it and might also affect the impact of the vulnerability. In addition, if the application performs any validation or other processing on the submitted data before it is reflected, this will generally affect what kind of XSS payload is needed.

Stored cross-site scripting:  Stored cross-site scripting (also known as second-order or persistent XSS) arises when an application receives data from an untrusted source and includes that data within its later HTTP responses in an unsafe way. 

Suppose a website allows users to submit comments on blog posts, which are displayed to other users. Users submit comments using an HTTP request like the following:

POST /post/comment HTTP/1.1
        Host: vulnerable-website.com
        Content-Length: 100

        postId=3&comment=This+post+was+extremely+helpful.&name=Carlos+Montoya&email=carlos%40normal-user.net

After this comment has been submitted, any user who visits the blog post will receive the following within the application’s response:

<p>This post was extremely helpful.</p>

Assuming the application doesn’t perform any other processing of the data, an attacker can submit a malicious comment like this:

<script>/* Bad stuff here... */</script>

Within the attacker’s request, this comment would be URL-encoded as:

comment=%3Cscript%3E%2F*%2BBad%2Bstuff%2Bhere...%2B*%2F%3C%2Fscript%3E

Any user who visits the blog post will now receive the following within the application’s response:

<p><script>/* Bad stuff here... */</script></p>

The script supplied by the attacker will then execute in the victim user’s browser, in the context of their session with the application.

To prevent XSS attacks, website and application developers must implement secure coding practices and validation mechanisms to ensure that user input is properly sanitized and validated. This involves filtering out any malicious code that may be included in user input, such as scripts or HTML tags. Additionally, developers can use security tools and techniques, such as Content Security Policy (CSP), to further protect against XSS attacks.

In SpringBoot Java built in Spring security can be used to prevent XSS attacks:

@Configuration
public class SecurityConf {
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.headers()
                .xssProtection()
                .and()
                .contentSecurityPolicy("script-src 'self'");
        return http.build();
    }
}

The 3rd most common attack which developers can avoid using secure coe practices is Buffer Overflow.

What is Buffer Overflow?

Almost every computer has a buffer. A buffer, or data buffer, is an area of physical memory storage used to temporarily store data while it is being moved from one place to another. These buffers typically live in RAM memory. Computers frequently use buffers to help improve performance; most modern hard drives take advantage of buffering to efficiently access data, and many online services also use buffers. 

For example, buffers are frequently used in online video streaming to prevent interruption. When a video is streamed, the video player downloads and stores perhaps 20% of the video at a time in a buffer and then streams from that buffer. This way, minor drops in connection speed or quick service disruptions won’t affect the video stream performance. 

Buffers are designed to contain specific amounts of data. Unless the program utilizing the buffer has built-in instructions to discard data when too much is sent to the buffer, the program will overwrite data in memory adjacent to the buffer.

 A buffer overflow can be:
 Accidental:You try to do too much within one program, and you exceed the space the program gives you. The program may begin to behave erratically, and in some cases, it may stop working altogether. 
Intentional:Someone sends in data that’s too large for your program. That dataset contains code that can replace the valid versions. When the new code runs, it can make the program do things you don’t expect. 
It may seem difficult for a hacker to craft a program that both understands your program completely and can change the way it works. But unfortunately, these attacks are relatively common.

Buffer overflow is an anomaly that occurs when software writing data to a buffer overflows the buffer’s capacity, resulting in adjacent memory locations being overwritten. In other words, too much information is being passed into a container that does not have enough space, and that information ends up replacing data in adjacent containers. Buffer overflows can be exploited by attackers with a goal of modifying a computer’s memory in order to undermine or take control of program execution.