Web Application Security Theory

Question 1

What is the golden rule of web application security

Answer 1

The client is never trustworthy

Question 2

What does the golden rule means in practice?

Answer 2

We need to filter and check carefully anything that is sent to us

Question 3

What are the possibilities for implementing filtering?

Answer 3

Whitelisting, only allowing through what we expect

Blacklisting, discard known bad stuff

Escaping, transform special characters into something else which is less dangerous

Question 4

Blacklisting is safer than whitelisting

True or false

Answer 4

False

Question 5

What is XSS?

Answer 5

Cross site scripting, is a vulnerability by means of which client side code can be injected in a page

Question 6

What are the types of XSS

Answer 6

Stored XSS

Reflected XSS

Dom-based XSS

Question 7

Describe the stored cross site scripting

Answer 7

The attacker input is stored on the target server in a database. Then the victim retrieves the stored, malicious code from the web application without that data being made safe to render in the browse.

Question 8

Describe how the reflected XSS happens

Answer 8

A reflected Cross-Site Scripting (XSS) attack occurs when an attacker injects malicious scripts into a website, which are then reflected off a web server and executed in a user’s browser. These scripts are often included in a URL or input field and are processed by the server, then sent back to the user’s browser without proper validation or encoding.

Here’s a breakdown of how a reflected XSS attack typically works:

1.	Injection: The attacker crafts a malicious URL or input that contains JavaScript or other executable scripts.
2.	Submission: The victim clicks on the malicious link or submits a form with the malicious input.
3.	Reflection: The web server processes the input and includes it in the response back to the user’s browser without proper sanitization.
4.	Execution: The user’s browser executes the malicious script, which can then perform actions like stealing cookies, session tokens, or other sensitive information, and sending it back to the attacker.

Question 9

What is the main difference between Stored and Reflected XSS

Answer 9

• Persistence: Stored XSS is persistent and affects any user accessing the compromised data, while reflected XSS is transient and targets individual users who interact with the malicious input.
• Attack Vector: Stored XSS typically requires an attacker to inject the script into a part of the application where it will be saved and viewed by users later. Reflected XSS requires the attacker to convince a user to click a link or submit a form containing the malicious script.

Question 10

Describe the DOM based XSS

Answer 10

A DOM-based Cross-Site Scripting (XSS) attack is a type of XSS where the vulnerability exists in the client-side code rather than the server-side code. In this scenario, the malicious script is injected and executed entirely within the Document Object Model (DOM) of the user’s browser.

How DOM-based XSS Works

1.	Injection: The attacker crafts a malicious URL or input that manipulates the client-side script.
2.	Execution: When the victim’s browser processes the page, the client-side JavaScript reads and executes the malicious payload from the URL or other client-side sources like document.location, document.referrer, or document.cookie.
3.	Result: The script is executed within the context of the page, leading to the same kinds of effects as reflected or stored XSS, such as data theft, session hijacking, or defacement.

Question 11

What can be done with cross site scripting

Answer 11

Cookie theft or section hijack

Manipulation of a section and execution of fraudulent transaction

Snooping on private information

Drive by download

Effective bypass, the same origin policy

Question 12

Define the same origin policy (SOP)

Answer 12

All client side code loaded from origin A should only be able to access data from origin A

Question 13

What is the problem of SOP?

Answer 13

Modern web has blurry boundaries (cross origin resource sharing, client side extensions)

Question 14

What does CSP stand for and what are its uses?

Answer 14

It stands for content security policy. It is a world wild Web consortium (W3C) specification to inform the browser on what should be trusted, and what not should be trusted.

Technically, it’s a set of directives sent by the server to the client in the form of HTTP response Heather.

Question 15

Discuss an example of a CSP policy enforcement

Answer 15

Client ← Server:
Content-Security-Policy: script-src ‘self’ https://apis.google.com

Client (attacker) → Server:
XSS to permanently inject

Client (victim) ← Server:

<html> ...

<script>
</html>

Browser refuses to load script
</script>

</html>

Question 16

What are the trade-off of CSP?

Answer 16

Strict policies break some functionalities

Relaxed policies can be bypassed

Question 17

What is a SQL injection?

Answer 17

SQL Injection is a type of security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. It occurs when an attacker is able to insert or manipulate SQL code in such a way that it is executed by the database, potentially leading to unauthorized access, data leakage, or manipulation.

Question 18

How SQL injection works

Answer 18

1. Injection Point: The attacker finds an input field in the application, such as a login form, search box, or URL parameter, where SQL queries are processed.
   
   2. Malicious Input: The attacker provides specially crafted input containing SQL code. This input is designed to modify the intended SQL query.
   3. Execution: The application executes the modified query, which can lead to various outcomes depending on the nature of the injected SQL.

Question 19

What is a blind injection and how does an attacker exploit it?

Answer 19

Blind SQLi: The attacker cannot see the results of the query directly but can infer them based on the application’s behavior.
• Boolean-based Blind SQLi: The attacker sends queries that result in true or false conditions and observes the application’s response.
• Time-based Blind SQLi: The attacker sends queries that cause delays in the database response and infers information based on the response time.

Question 20

How do we make SQL injections more difficult

Answer 20

Input sanitization (validation and filtering)

Using prepared statements (parametric query) instead of building query strings

Not using table names as field names

Limitations on query privileges, different users can execute different types of queries on different tables

Question 21

How does the security requirement of never mix code and data, conflict with the web functional requirement and what is the consequence of that?

Answer 21

The functional requirement of a Web sometimes enforces to mix code and data.

The consequence of that is, if, at any point, there is a parser routine (EX, the browsers JavaScript parser) that reacts (EX, prints something) on some control sequences found in the data, we have a vulnerability

Question 22

What are Freudian slips?

Answer 22

In the context of computer security, “Freudian slips” can be seen as analogous to human errors or unintentional actions that reveal underlying vulnerabilities or security weaknesses in systems and practices. These “slips” in cybersecurity can lead to unintended consequences that compromise security.

Question 23

What are some examples of Freudian Slips?

Answer 23

Error messages containing sensitive information

Insertion of user supplied data in errors (reflected XSS risk)

Debug traces active in production. They can reveal: server and application versions, database names, structure, and credential, path names.

Side–channels (EX, user not found VS password mismatch)

Question 24

Define a session creation and identification using cookies

Answer 24

See picture 4S in the Comp Sec album

Question 25

What are some security issues with sessions created by cookies?

Answer 25

Prevent prediction of the token a client received or will receive, to prevent impersonations/spoofing attacks, minimize damage of session stealing

Any token Should have a reasonable expiration period

Cookie encryption and storage

Question 26

Due to the fact, that HTTPis a stateless what are the types of hijacking that can occur

Answer 26

Stealing a cookie with a XSS attack

Brute forcing a weak session ID parameter

Question 27

What does CSRF stands for?

Answer 27

Cross site request forgery

Question 28

Define CSRF

Answer 28

Forces an user to execute unwanted actions (state changing action) on a web application in which he or she is currently authenticated with ambient credentials (EX, with cookies)

Question 29

Discuss how a CSRF can occur

Answer 29

Key Concept:
● Cookies are used for session management.
● All the requests originating by the browser come with the
user’s cookies (cookies are ambient credentials: they are
sent automatically for every request).
● Malicious requests (e.g., crafted links) are routed to the
vulnerable web application through the victim’s browser.
● Websites cannot distinguish if the requests coming from
authenticated users have been originated by an explicit user interaction or not.

Question 30

Discuss a CSRF example for a malicious bank transfer

Answer 30

See picture 5S in the Comp Sec album

Question 31

What is the main mitigation for CSRF?

Answer 31

The CSRF token

Question 32

How does a CSRF token works

Answer 32

How CSRF Tokens Work

1.	Token Generation: When a user visits a web application, the server generates a unique CSRF token for that user session. This token is a random value that is difficult for an attacker to guess.
2.	Token Storage: The CSRF token is stored on the server side and is also included in the client’s web page, typically as a hidden form field or as a value in the session storage or a cookie.
3.	Token Validation: When the user submits a form or makes a state-changing request, the CSRF token is included in the request. The server then checks the token received from the client against the token it generated and stored.
4.	Action Authorization: If the token is valid and matches the stored token, the server processes the request. If the token is missing or incorrect, the server rejects the request, preventing the CSRF attack.

Question 33

What is another mitigation for CSRF

Answer 33

Same site cookies

The main idea is to not send session cookies at all for requests originating from different websites.

This way a request that was induced by an attacker do not contain the authentication cookie, possibly present in the client cash.

Question 34

How can a same site cookie be specified?

Answer 34

They are specified when the website is created by setting the SameSite attribute

The SameSite attribute can be set to one of three values: Strict, Lax, or None. Each of these values offers a different level of protection against CSRF attacks:

1. SameSite=Strict
   • Behavior: Cookies with the SameSite=Strict attribute are not sent with any cross-site requests, including links clicked from another site.
2. SameSite=Lax
   • Behavior: Cookies with the SameSite=Lax attribute are sent with top-level navigation requests (e.g., when the user clicks a link to the site) but not with subrequests (e.g., images or iframes from another site).