“Aren’t you a little short for a Stormtrooper?” In this iconic Star Wars moment, Princess Leia lazily responds to Luke Skywalker, disguised as one of her Stormtrooper captors and using authentication information to open her cell.

In other words, Star Wars acts as an analogy for a cross-site request forgery (CSRF) attack. In a CSRF attack, malicious actors use social engineering so that end-users will give them a way to “hide” in their authenticated session. Disguised as the victim, the attackers can make changes and engage in transactions based on the account’s permissions.

With a cross-site request forgery cheat sheet, you can learn the basic principles underlying these attacks and some best mitigation practices.

What is Cross-Site Request Forgery (CSRF)?

A cross-site request forgery (CSRF) attack involves inheriting the victim’s identity and privileges so that the attacker can perform actions within the site. Typically, browser requests include credential information, like a user’s:

• Session cookie
• IP address
• Windows domain credentials

After a user authenticates into the site, the attackers target functions that allow them to make changes, like:

• Changing an email address
• Creating a new password
• Making a purchase
• Transferring funds
• Elevating privileges

The site treats these forged, authenticated requests as legitimate and authorized. The attacks focus on making changes within the site because any data requested would go to the victim.

CSRF attacks can also be called:

• XSRF
• Sear Surf attacks
• Session Riding
• Cross-Site Reference Forgery
• Hostile Linking

Three Types of CSRF Attacks

Malicious actors can deploy three types of CSRF attacks.

LOGIN CSRF Attack

In a login CSRF attack, malicious actors:

• Get the user to log into an account the threat actor controls
• Victim adds personal data to the account
• Attackers log into the account to collect data and victim activity history

Stored CSRF Flaws

Attackers can store an attack on a vulnerable site using fields that accept HTML using:

• IMG tag
• IFRAME tag

This increases the damage of the attack for two reasons:

• Victims may “trust” the compromised site.
• Victims may already be authenticated into the site.

Client-side CSRF

The client-side CSRF attack manipulates the client-side JavaScript program’s requests or parameters, sending a forged request that tricks the target site. These attacks rely on input validation issues so the server-side has no way to determine whether the request was intentional.

How does a CSRF attack work?

At a high level, attackers do two things:

• Create the malicious code
• Use social engineering to trick the victim

CSRF attacks rely on:

• Web browsers handling session-related information
• Attackers’ knowledge of web application URLs, requests, or functionality
• Application session management only using browser information
• HTML tags that provide immediate HTTP[S] resource access

By clicking on the malicious URL or script, the victim sets up the attacker’s ability to exploit:

• GET requests: Browser submits the unauthorized request.
• POST requests: Victim clicking on a link or submit button executes the action.
• HTTP methods: APIs using PUT or DELETE could have requests embedded into an exploit page, but same-origin policy restrictions in browsers can protect against these unless the website explicitly allows these requests.

How is Cross-Site Request Forgery Different from Cross-Site Scripting (XSS)?

These attacks exploit different aspects of web interactions:

• Cross-Site Request Forgery: leverages use identity to take state-changing actions without victim consent
• Cross-site scripting: inject malicious code into web pages to manipulate user input and access sensitive data

Best Practices for Mitigating CSRF Attack Risk

A successful CSRF attack exploits specific application vulnerabilities and a user’s privileges. Following some best practices, you can mitigate these risks.

Use Synchronizer Token Patterns

As the most effective mitigation, many frameworks include CSRF protection by default so you may not have to build one yourself. The server-side-generated CSRF tokens should be:

• Unique per user per session
• Secret
• Unpredictable

The server-side component verifies the token’s existence and validity, comparing it to the token in the user session and the site should reject the request without it.

The mitigation uses per-session tokens because they offer the end-user a better experience. A per-request token would be more secure by limiting the available time frame for using them. However, for every user interaction, the site would need to generate a new token.

Alternative: Signed Double-Submit Cookie Patterns

In cases where you can’t use the synchronizer token, you could substitute the easy-to-implement, stateless Double-Submit Cookie pattern. With the Signed Double-Submit Cookie, you have a secret key that only the server knows to mitigate injection risks that would compromise the victim’s session.

While the Naive Double-Submit Cookie methods may be easier to implement and scale, attackers can bypass the protection more easily through:

• Subdomain exploitation
• Man-in-the-middle (MitM) attacks

Disallow Simple Requests

Simple requests are cross-origin HTTP requests that can be sent directly from the browser to the target service without getting prior approval. If the site uses <form> tags that allow users to submit data, the application should include additional protections. Some examples of additional protections include:

• Ensuring servers or APIs do not accept text/plain content types
• Implementing custom request headers for AJAX/APIs to prevent usability issues that using a double-submit cookie would create

Implement Client-side CSRF Mitigations

Since client-side CSRF attacks bypass traditional mitigations, you should implement the following:

• Independent requests: Ensure attacker controllable inputs cannot generate asynchronous requests
• Input validation: Ensure that input formats and request parameter values only work for non-state-changing operations
• Predefined Request Data: Store safe request data in the JavaScript code

SameSite (Cookie Attribute)

The browser uses this attribute to determine whether to send cookies with cross-site requests and has three potential values:

• Strict: prevents the browser from sending the cookie to the target site in all cross-site browsing contexts that involve following a regular link
• Lax: maintains a logged-in session when the user follows an external link, but blocks high-risk request methods

Verify Origin with Standard Headers

This method examines the HTTP request header value for:

• Source origin: where it comes from
• Target origin: where it’s going to

When these match, the site accepts the request as legitimate. If they do not match, it discards the request.

Involve the User

Involving users means they have to take action that mitigates risks from unauthorized operations. Some examples include using:

• Re-authentication mechanisms
• One-time tokens

While CAPTCHA requires user interaction, it does not always differentiate user sessions. While it would make attacker success more difficult, it isn’t a suggested mitigation technique.

Graylog Security: Mitigating CSRF Risk with High Fidelity Alerts

Graylog Security provides prebuilt content that maps security events to MITRE ATT&CK so organizations can enhance their security posture. By combining Sigma rules and MITRE ATT&CK, you can create high-fidelity alerting rules that enable robust threat detection, lightning-fast investigations, and streamlined threat hunting. For example, with Graylog’s security analytics, you can monitor user activity for anomalous behavior indicating a potential security incident. By mapping this activity to the MITRE ATT&CK Framework, you can detect and investigate adversary attempts at using Valid Accounts to gain Initial Access, mitigating risk by isolating compromised accounts earlier in the attack path and reducing impact.

Graylog’s risk scoring capabilities enable you to streamline your threat detection and incident response (TDIR) by aggregating and correlating the severity of the log message and event definitions with the associated asset, reducing alert fatigue and allowing security teams to focus on high-value, high-risk issues.

“Aren’t you a little short for a Stormtrooper?” In this iconic Star Wars moment, Princess Leia lazily responds to Luke Skywalker, disguised as one of her Stormtrooper captors and using authentication information to open her cell.

In other words, Star Wars acts as an analogy for a cross-site request forgery (CSRF) attack. In a CSRF attack, malicious actors use social engineering so that end-users will give them a way to “hide” in their authenticated session. Disguised as the victim, the attackers can make changes and engage in transactions based on the account’s permissions.

With a cross-site request forgery cheat sheet, you can learn the basic principles underlying these attacks and some best mitigation practices.

What is Cross-Site Request Forgery (CSRF)?

A cross-site request forgery (CSRF) attack involves inheriting the victim’s identity and privileges so that the attacker can perform actions within the site. Typically, browser requests include credential information, like a user’s:

• Session cookie
• IP address
• Windows domain credentials

After a user authenticates into the site, the attackers target functions that allow them to make changes, like:

• Changing an email address
• Creating a new password
• Making a purchase
• Transferring funds
• Elevating privileges

The site treats these forged, authenticated requests as legitimate and authorized. The attacks focus on making changes within the site because any data requested would go to the victim.

CSRF attacks can also be called:

• XSRF
• Sear Surf attacks
• Session Riding
• Cross-Site Reference Forgery
• Hostile Linking

Three Types of CSRF Attacks

Malicious actors can deploy three types of CSRF attacks.

LOGIN CSRF Attack

In a login CSRF attack, malicious actors:

• Get the user to log into an account the threat actor controls
• Victim adds personal data to the account
• Attackers log into the account to collect data and victim activity history

Stored CSRF Flaws

Attackers can store an attack on a vulnerable site using fields that accept HTML using:

• IMG tag
• IFRAME tag

This increases the damage of the attack for two reasons:

• Victims may “trust” the compromised site.
• Victims may already be authenticated into the site.

Client-side CSRF

The client-side CSRF attack manipulates the client-side JavaScript program’s requests or parameters, sending a forged request that tricks the target site. These attacks rely on input validation issues so the server-side has no way to determine whether the request was intentional.

How does a CSRF attack work?

At a high level, attackers do two things:

• Create the malicious code
• Use social engineering to trick the victim

CSRF attacks rely on:

• Web browsers handling session-related information
• Attackers’ knowledge of web application URLs, requests, or functionality
• Application session management only using browser information
• HTML tags that provide immediate HTTP[S] resource access

By clicking on the malicious URL or script, the victim sets up the attacker’s ability to exploit:

• GET requests: Browser submits the unauthorized request.
• POST requests: Victim clicking on a link or submit button executes the action.
• HTTP methods: APIs using PUT or DELETE could have requests embedded into an exploit page, but same-origin policy restrictions in browsers can protect against these unless the website explicitly allows these requests.

How is Cross-Site Request Forgery Different from Cross-Site Scripting (XSS)?

These attacks exploit different aspects of web interactions:

• Cross-Site Request Forgery: leverages use identity to take state-changing actions without victim consent
• Cross-site scripting: inject malicious code into web pages to manipulate user input and access sensitive data

Best Practices for Mitigating CSRF Attack Risk

A successful CSRF attack exploits specific application vulnerabilities and a user’s privileges. Following some best practices, you can mitigate these risks.

Use Synchronizer Token Patterns

As the most effective mitigation, many frameworks include CSRF protection by default so you may not have to build one yourself. The server-side-generated CSRF tokens should be:

• Unique per user per session
• Secret
• Unpredictable

The server-side component verifies the token’s existence and validity, comparing it to the token in the user session and the site should reject the request without it.

The mitigation uses per-session tokens because they offer the end-user a better experience. A per-request token would be more secure by limiting the available time frame for using them. However, for every user interaction, the site would need to generate a new token.

Alternative: Signed Double-Submit Cookie Patterns

In cases where you can’t use the synchronizer token, you could substitute the easy-to-implement, stateless Double-Submit Cookie pattern. With the Signed Double-Submit Cookie, you have a secret key that only the server knows to mitigate injection risks that would compromise the victim’s session.

While the Naive Double-Submit Cookie methods may be easier to implement and scale, attackers can bypass the protection more easily through:

• Subdomain exploitation
• Man-in-the-middle (MitM) attacks

Disallow Simple Requests

Simple requests are cross-origin HTTP requests that can be sent directly from the browser to the target service without getting prior approval. If the site uses <form> tags that allow users to submit data, the application should include additional protections. Some examples of additional protections include:

• Ensuring servers or APIs do not accept text/plain content types
• Implementing custom request headers for AJAX/APIs to prevent usability issues that using a double-submit cookie would create

Implement Client-side CSRF Mitigations

Since client-side CSRF attacks bypass traditional mitigations, you should implement the following:

• Independent requests: Ensure attacker controllable inputs cannot generate asynchronous requests
• Input validation: Ensure that input formats and request parameter values only work for non-state-changing operations
• Predefined Request Data: Store safe request data in the JavaScript code

SameSite (Cookie Attribute)

The browser uses this attribute to determine whether to send cookies with cross-site requests and has three potential values:

• Strict: prevents the browser from sending the cookie to the target site in all cross-site browsing contexts that involve following a regular link
• Lax: maintains a logged-in session when the user follows an external link, but blocks high-risk request methods

Verify Origin with Standard Headers

This method examines the HTTP request header value for:

• Source origin: where it comes from
• Target origin: where it’s going to

When these match, the site accepts the request as legitimate. If they do not match, it discards the request.

Involve the User

Involving users means they have to take action that mitigates risks from unauthorized operations. Some examples include using:

• Re-authentication mechanisms
• One-time tokens

While CAPTCHA requires user interaction, it does not always differentiate user sessions. While it would make attacker success more difficult, it isn’t a suggested mitigation technique.

Graylog Security: Mitigating CSRF Risk with High Fidelity Alerts

Graylog Security provides prebuilt content that maps security events to MITRE ATT&CK so organizations can enhance their security posture. By combining Sigma rules and MITRE ATT&CK, you can create high-fidelity alerting rules that enable robust threat detection, lightning-fast investigations, and streamlined threat hunting. For example, with Graylog’s security analytics, you can monitor user activity for anomalous behavior indicating a potential security incident. By mapping this activity to the MITRE ATT&CK Framework, you can detect and investigate adversary attempts at using Valid Accounts to gain Initial Access, mitigating risk by isolating compromised accounts earlier in the attack path and reducing impact.

Graylog’s risk scoring capabilities enable you to streamline your threat detection and incident response (TDIR) by aggregating and correlating the severity of the log message and event definitions with the associated asset, reducing alert fatigue and allowing security teams to focus on high-value, high-risk issues.

Everyone remembers that one required writing class they needed to take. If you’re like a lot of other security analysts, you assumed that your job would focus on using technology, not writing research papers. However, in today’s business environment, cyber incidents are critical business events, especially as governments and agencies create more reporting requirements.

A cyber incident report is a key element for your incident response process, especially when your organization reviews activities to identify areas of improvement during the lesson’s learned phase. When implementing a structured incident response plan, you should know what an IT security incident response report is, why you need one, and what it should contain.

What Is Cyber Incident Reporting?

Cyber incident reporting involves documenting the details of incidents like:

• Cyber attacks
• Data breaches
• Unauthorized access

The IT security report typically details an incident’s timeline, including:

• Date of incident
• Attacker activities and timing
• Accounts, resources, and/or data affected
• Remediation steps taken

Cyber reporting is a critical part of the incident response process because organizations can use the documents as part of:

• Lessons learned: Assessing incident detection and response to identify areas of improvement
• Implementing controls: Developing new controls to prevent a similar incident from occurring in the future
• Notification requirements: Communicating with affected parties or others as required by law

Why Are IT Security Reports Important?

Documenting an incident’s details and notifying relevant stakeholders promptly provides various benefits.

Maintain Compliance

Most legal and regulatory frameworks require organizations to report cybersecurity incidents to various involved parties, including:

• Law enforcement
• Cybersecurity agencies
• Affected parties, like individuals or companies whose data was compromised

Laws have varying timelines for providing notification. For example, the General Data Protection Regulation (GDPR) mandates that organizations report a data breach within 72 hours. Meanwhile, under the Health Insurance Portability and Accountability Act (HIPAA), covered entities must notify affected parties within 60 days.

Failure to comply with these notification requirements can lead to fines or other penalties.

Improve Risk and Threat Awareness

A detailed cyber security incident report provides insight into potential weaknesses. By analyzing the incident’s underlying causes, security teams can improve their risk models and close security gaps. The organization can use this information to address new threats then implement new security controls to mitigate risk.

Build Trust With Clients, Customers, and Stakeholders

Transparency during data breaches builds trust with stakeholders by demonstrating professionalism and urgency. Open communication about incidents reinforces that no organization is immune to cyber threats, showcasing commitment to data protection. While the organization will remove sensitive information related to its own security, the IT security incident report provides a timeline that can act as the foundation for these communications.

Cyber Reporting Challenges

Reporting, like compliance, is a process that can become overwhelming, especially for understaffed security teams.

Gathering Information

Under the pressure of an ongoing incident, security teams need to investigate quickly. Isolation and recovery are the critical steps. They document their activities, but they have no time to organize their documentation. Once they contain the threat and recover systems, they spend time putting the puzzle pieces together.

Creating a timeline

In a perfect world, incident investigations start with the first alert that the attackers trigger. Across complex, interconnected systems, the activity that initiates an investigation may not be that first alert. Additionally, many alerts only provide a quick glimpse into a moment in time. For example, Sigma rules provide insight that an event occurred but often lack context, like previous or follow up events.

Turning data into a narrative

Alerts and ticketing system notes are simply data points. They provide insight into discrete actions. For a cybersecurity incident report, analysts need to turn these events into a narrative. For example, the system may have sent a Windows Event alert with the ID 4625, “attempt made to logon with unknown user name or bad password and failed.” However, the security analyst needs to translate that “what happened” into the “why it matters.”

Using sensitive environment data

Although large language models (LLMs) can turn raw data into a narrative, cyber incident report data contains sensitive information, including user IDs or internal identifiers. Unfortunately, feeding data into a public LLM makes that information part of the technology’s database, creating a data leak issue.

What Needs to Be in a Cyber Security Incident Report?

Since organizations use IT security reports to document and learn from incidents, reports need to include technical and non-technical information that outlines various event details.

Executive summary

The executive summary provides a clear, concise overview of the cybersecurity incident for a broad audience, highlighting:

• Key finding
• Actions taken
• Impact on stakeholder
• Incident ID
• Incident summary, with type, time, duration, and affected systems/data

Incident details

This section captures critical information about the incident, including:

• Nature of threat
• Business impact
• Immediate actions taken
• When/how incident occurred
• Who/what was affected
• Overall scope

Attack vector details

Attack vector details identify the specific vulnerabilities that attackers exploited, including technical details like:

• Open ports
• Weak credentials
• Phishing URLS
• Source IP addresses for Distributed Denial of Service (DDoS) attacks

Systems and assets affected

This section outlines the technology assets impact, including:

• Servers
• Storage
• Network device
• User devices

Additionally, it details the damage that the incident causes, like data corruption, to evaluate the impact on business operations.

Business impact assessment

A business impact assessment evaluates the operational disruptions and data compromises resulting from the cyber incident. It reviews any

• Financial losses
• Regulatory implications
• Long-term consequences

Incident response actions

Incident response actions highlight the steps taken from detection to remediation, including

• Preparation
• Containment
• Recovery

Detailing these activities can identify areas of improvement that enable the organization to update controls.

Communication and notification logs

Communication and notification logs show how the organization shared information about the incident for compliance and accountability purposes. These logs detail communications with all affected parties informed, including

• Internal teams
• External stakeholders
• Regulatory authorities

Conclusions

In the conclusions, the cybersecurity incident report provides a comprehensive overview of the event, its impact, and insights for future prevention.

Graylog Security: Responsible AI for Automating IT Security Incident Reporting

Reading every log generated during a security incident is overwhelming, but the individual logs are only limited pieces of discrete information. To gain full visibility into an incident, you need to aggregate the data and understand the timeline.

With Graylog Security, you can create AI-generated incident reports using your organization’s log data while maintaining control and security over the information in the logs. At the click of a button, our AI interface analyzes all the logs and provides a report based on what it found, what it sees happening based on the data, and recommendations for mitigating the issue. Since all data you need remains in your Graylog deployment or in Data Warehouse, you maintain control, security, and privacy over your most sensitive environment data.