Important

Question 1

CSRF Prevention

Answer 1

To prevent CSRF attacks, web applications need to build mechanisms to distinguish a legitimate request by a trusted user from a forged request crafted by an attacker but sent by the trusted user.

Token Based Mitigation:
- some frameworks like .NET have built-in protections that add a token to vulnerable CSRF resources.
- Synchronizer token pattern: csrf tokens should be generated server-side. They can be generated once per-user session for requests. The value is stored in the session and used for each request until the session expires. The server needs to verify the token in the request to the one found in the user session
- the token should be transmitted as part of the response and then transmitted back to the server as part of a hidden field on a form submission or as a AJAX header/part of JSON payload
- more secure to put it in a custom header (automatically same origin policy applies)

Double Submit Cookie:
- this is stateless unlike token-based mitigations
- server doesn’t need to generate the value, the client could
- the value will be sent as a cookie and as something else (request header)
- the attacker cannot access the cookie
- so the attacker cannot send the value as something else to verify itself (like in a request header) - this step needs to happen

Signed Double Submit Cookie:
- server has a secret key
- tokens are hashed/encrypted
- A simpler alternative to an encrypted CSRF cookie is to use HMAC (Hash-based Message Authentication Code) to hash the random value with a secret key known only by the server and place this value in a cookie.
- attacker cannot submit their own CSRF cookie

Custom request headers:
- no token
- In this pattern, the client appends a custom header to requests that require CSRF protection. The header can be any arbitrary key-value pair, as long as it does not conflict with existing headers.
- When handling the request, the API checks for the existence of this header. If the header does not exist, the backend rejects the request as potential forgery.
- this relies on SOP (that only JS can add the header and only from within its origin). By default, browsers do not allow JavaScript to make cross origin requests with custom headers. Only JavaScript that you serve from your origin can add these headers.

Question 2

CSRF defense in depth protections

Answer 2

SameSite Cookie Attribute:
- helps browser decide whether to send cookies along with cross-site requests.
- lax, strict, none

Verify origin with standard headers
- check if source origin matches target origin

Question 3

Client Side CSRF

Answer 3

the attacker tricks the client-side javascript code to send a forged HTTP request to the vulnerable target by manipulating the program’s input parameters
- Client-side CSRF originates when the JavaScript program uses attacker-controlled inputs, such as the URL, for the generation of asynchronous HTTP requests.
- it can bypass some CSRF mitigations like tokens
- circumvents same-site cookie

Question 4

bypassing CSRF mitigations

Answer 4

Some applications correctly validate the token when it is present but skip the validation if the token is omitted.

Some applications do not validate that the token belongs to the same session as the user who is making the request. Instead, the application maintains a global pool of tokens that it has issued and accepts any token that appears in this pool.
In this situation, the attacker can log in to the application using their own account, obtain a valid token, and then feed that token to the victim user in their CSRF attack.

Bypassing same-site:
Open redirection -As far as browsers are concerned, these client-side redirects aren’t really redirects at all; the resulting request is just treated as an ordinary, standalone request. Most importantly, this is a same-site request and, as such, will include all cookies related to the site, regardless of any restrictions that are in place.

Question 5

What happens when you enter a URL into the browser and hit enter?

Answer 5

1. URL parsing - protocol, domain, path, query parameters
2. DNS Lookup - check cache. Make a request to DNS server to find ip associated with the domain
3. TCP Handshake
4. TLS Handshake
5. HTTP Request
6. Server Processing
7. HTTP Response
8. Page rendering

Question 6

How do you analyze a suspicious email attachment?

Answer 6

1. Open on a virtual machine like virtual box with no network access.
2. Take a snapshot of the virtual machine before and after
   - see processes launched, ports, etc

The easiest way would be to foward the mail to an online scanning service. Or download (do not run) and upload to virus/malware scanner.

Look at the file type

Inspect the email. Sender. Typos. etc

Question 7

How do you attack a VPN?

Answer 7

Weak ciphers that can be broken. Browser activity could be leaked if DNS requests are being handled by the ISP. These are unencrypted.

Question 8

How do you find vulnerable software running on people’s work machines?

Answer 8

Endpoint management system running that will detect vulnerable software. See what processes are running. SentinelOne.

Question 9

You visit a team website and get a 404, but everyone else on your team can access it. what is wrong?

Answer 9

Maybe you’re in the wrong role. Okta. Don’t have the right permissions.

Delete your cache.

Question 10

A CEO of a well known company is sitting across from you at a coffee shop. how do you hack his email?

Answer 10

Is a public wifi being used. It’s safe as long as the websites you’re using are using HTTPS. Otherwise, someone else connected to the wifi can sniff your traffic content.

Look over his shoulder for passwords. Figure out what his email address is. Phish him. Send him to a site without HTTPS or to my own malicious site.

Wifi pineapple to mimic a network and have the CEO connect to the wifi pineapple.

Question 11

Your manager wants you to bring you laptop to Defcon, how do you secure it from getting hacked?

Answer 11

Turn off wifi. Encrypt the machine. Make sure it’s updated/patched. Host based firewall. Turn off bluetooth.

Question 12

If you were an attacker who compromised a CA and stole the private key, how would you use it?

Answer 12

Can issue fraudulent certificates.

Question 13

How would you attack the OAuth workflow?

Answer 13

Implementation mistakes.

Take advantage of the redirect_uri for Open Redirects. the client application implements some whitelist of their genuine callback URLs when registering with the OAuth service to mitigate this attack. Could end up sending the access token to an attacker controlled url. CSRF like attack to trick the user into initiating the OAuth flow, but sending the token back to the malicious user.

Need to add the state parameter - needs to be an unguessable value. Otherwise vulnerable to CSRF. Because It potentially means that they can initiate an OAuth flow themselves before tricking a user’s browser into completing it, similar to a traditional CSRF attack.

Pre account takeover. Try to register an account with another user’s email. Then we they try to create an account using social network, then that will get linked to the pre existing account. Perhaps they can still login into the account using the pw they set.

OAuth authentication vulnerabilities arise partly because the OAuth specification is relatively vague and flexible by design. Lack of built-in security features
the first request of the flow will always be a request to the /authorization endpoint containing a number of query parameters that are used specifically for OAuth. In particular, keep an eye out for the client_id, redirect_uri, and response_type parameters

Question 14

Explain the SSL handshake. How do certificates get provisioned?

Answer 14

They get provisioned by a CA. You send a request to a CA such as Verisign.

An applicant generates a key pair (public and private) and a CSR (certificate signing request). A CSR is an encoded file that includes the public key and other info such as domain name, org, email). This is usually generated on the server that the certificate will be installed.

The private key is never sent to the CA.

The applicant sends the CSR to the CA. CA independently validates the info. If validated, then signs the cert with an issuing private key and sends it to the applicant.

Third parties can validate the cert by confirming the CA’s signature with the CA’s public key.

Question 15

You see a high volume of traffic to 169.254.169.254, what do you suspect?

Answer 15

This ip is used for instance metadata. Maybe they’re trying to see what kind of a server it is/where its hosted and try to gather more data about the server. Perhaps the server has been compromised.

Question 16

API Security

Answer 16

Use HTTPS
JWT
Input Validation
Error handling
SSO - you don’t have to manage user pw storage yourself
API Gateway

Question 17

XSS Prevention

Answer 17

• [ ] XSS Framework built in protections
  
  • [ ] React
  • [ ] Angular
  • [ ] But still need to use these frameworks safely
  • [ ] Cookie attributes - samesite, httponly
  • [ ] CSP
  • [ ] Web application firewalls

Question 18

What is a JSONP?

Answer 18

JSONP stands for JSON with padding. It is a method for sending JSON data without having to worry about cross domain issues (because of SOP). This was before the adoption of CORS.

JSONP enables sharing of data bypassing same-origin policy, which disallows running JavaScript code to read media DOM elements or XMLHttpRequest data fetched from outside the page’s originating site. The originating site is indicated by a combination of URI scheme, hostname, and port number.

JSONP uses the

 tag.

A server can send a function call (wrapped around JSON) returning JSON in a response. The client uses a script tag and the server url as the src to load this data by handling the function.
This “wrapped payload” is then interpreted by the browser. In this way, a function that is already defined in the JavaScript environment can manipulate the JSON data.

JSONP is vulnerable to the data source replacing the innocuous function call with malicious code, which is why it has been superseded by cross-origin resource sharing in modern applications.

You’re allowing a remote server to inject any content into your website. They could inject malicious javascript and because the script is bypassing SOP, it could lead to CSRF, fetching JS from another site, etc.

Question 19

Give examples of secure libraries encoding, sanitization

Answer 19

DOMPurify - recommended by OWASP for HTML sanitization
Use safe HTML attributes unlike innerHTML use innerText
Don’t pipe values into eval()

Question 20

What are some security network scanners?

Answer 20

NMAP
Wireshark
Burp

Question 21

What is a race condition and how do you prevent them?

Answer 21

A race condition attack takes advantage of a system that needs to execute tasks in a specific sequence.

For example:
2 users try to use an Amazon gift card at the exact time. If multiple workers pick up this task, how do we know not to process the card twice?

We can use mutexes/locks on the db item. Resource is only accessible by one thread at a time.

Question 22

What is seccomp?

Answer 22

Seccomp is a linux kernel security feature.

It restricts the system calls that can be made. The kernel will terminate/kill/log the process if any other system calls are attempted to be made.

Useful for containers/kubernetes. Can load a seccomp profile preconfigured with allowed/disallowed system calls.

seccomp-bpf is an extension to seccomp that allows filtering of system calls using a configurable policy implemented using Berkeley Packet Filter rules.

Question 23

What are some security hardening flags?

Answer 23

• Stack protector/canary - Adds runtime checks to detect buffer overflows and stack smashing
• PIC/PIE - for ASLR
• Wformat - Adds compile time checks to detect issues relating to format string arguments in common library functions such as printf, scanf, strftime, etc.
• fortify_source - Adds compile and run time checks to detect buffer overflows in memory and string functions

Question 24

What are some buffer overflow preventions?

Answer 24

• use a memory safe language
• use safe functions with bounds checking
• check bounds
• ASLR (security hardening flags)
• Stack canary
• DEP (data execution prevention) - mark certain parts of memory as non-executable
• static code analysis
• fuzzing

Question 25

What is a format string attack and how do you prevent it?

Answer 25

This could potentially leak sensitive values.

When an attacker can control the format string in printf, scanf, or another function in that family. The function will walk up the stack and look for the argument specified by the format string. This is because variables are placed on the stack. So when printf sees the format string, it will look on the stack for the first variable after the format string. But this could actually be return addresses, function pointers, etc.

printf is expecting the format string and arguments. If the arguments are not passed, then it’ll still just walk up the stack and print the values there.

Can also write to the stack. Could have arbitrary code execution.

Usually C is affected, but python is also vulnerable if format() is misconfigured.

To fix this, you need to include the format string specifier and not leave it up to user input, so that it doesn’t specify interpret user supplied format specifier.
Make the format string a constant.

Question 26

What’s the process for rotating a secret?

Answer 26

in aws:
- [ ] Create new secret version
- [ ] Change credentials in the db/service
- [ ] Test the new secret version
- [ ] Finish the rotation

Question 27

What is DOM-Based XSS?

Answer 27

All happens in the browser. The server is not hit for this attack to work. All happens in the DOM. No request to the server is made.

DOM-based XSS vulnerabilities usually arise when JavaScript takes data from an attacker-controllable source, such as the URL, and passes it to a sink that supports dynamic code execution, such as eval() or innerHTML.

To deliver a DOM-based XSS attack, you need to place data into a source so that it is propagated to a sink and causes execution of arbitrary JavaScript.

The most common source for DOM XSS is the URL, which is typically accessed with the window.location object. An attacker can construct a link to send a victim to a vulnerable page with a payload in the query string and fragment portions of the URL.

To test for DOM XSS in an HTML sink, place a random alphanumeric string into the source (such as location.search), then use developer tools to inspect the HTML and find where your string appears.

you should avoid allowing data from any untrusted source to be dynamically written to the HTML document.

Question 28

What is reflected XSS?

Answer 28

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.

The need for an external delivery mechanism for the attack means that the impact of reflected XSS is generally less severe than stored XSS

Question 29

What is Kafka and how do you secure a Kafka cluster?

Answer 29

Apache Kafka is an internal middle layer enabling your back-end systems to share real-time data feeds with each other through Kafka topics. With a standard Kafka setup, any user or application can write any messages to any topic, as well as read data from any topics.

Encryption of data in-flight using SSL / TLS

Authentication using mTLS

Authorization using ACLs

Question 30

What is Blind XSS?

Answer 30

Blind XSS is a type of stored XSS n which the data exit point is not accessible to the attacker, for example due to a lack of privileges.

The attack input could be executed in a completely different application. For instance, you upload an attack via a chat bot and then the attack executes when an admin views the chat in an internal dashboard.

To test for blind XSS you need to check if there was an out-of-bound interaction. i.e. have a request be made to a server you host and so when someone has the attack executed, you will see a request.

Harder to detect because the input is not reflected immediately. It could be months before the attack is triggered.

Question 31

How do you test for blind XSS?

Answer 31

You inject payloads into the web application. GET/POST requests, headers, etc.

Have the payload gather information and send it to a server for analysis.

Question 32

What does HMAC achieve and how does it work?

Answer 32

HMAC is a message encryption method that uses a cryptographic key in conjunction with a hash function. A secret key is provided that should be specific to only the server and client.

It is used for authentication and for message integrity.

HMAC = hashFunc(secret key + message)

The client creates a unique hash by hashing the request data with the private key and sending it as part of the request. The server receives the request and regenerates its own unique HMAC. It then compares the two HMACs. If they are equal, the client is trusted and considered legitimate, and the request is executed.

Difference with digital signature is that HMAC uses symmetric key and digital signatures use asymmetric keys. HMAC not used for non-repudiation unlike digital signature.

Question 33

How do you prevent path traversal?

Answer 33

The most effective way to prevent path traversal vulnerabilities is to avoid passing user-supplied input to filesystem APIs altogether.

Otherwise,
validate input properly. Whitelist
After validating the supplied input, append the input to the base directory and use a platform filesystem API to canonicalize the path. Verify that the canonicalized path starts with the expected base directory.

Question 34

What is IDOR?

Answer 34

Insecure direct object references (IDORs) are a subcategory of access control vulnerabilities. IDORs occur if an application uses user-supplied input to access objects directly and an attacker can modify the input to obtain unauthorized access.

Question 35

How do you prevent file upload vulnerabilities?

Answer 35

Check the file extension against a whitelist of permitted extensions rather than a blacklist of prohibited ones. It’s much easier to guess which extensions you might want to allow than it is to guess which ones an attacker might try to upload.
Make sure the filename doesn’t contain any substrings that may be interpreted as a directory or a traversal sequence (../).
Rename uploaded files to avoid collisions that may cause existing files to be overwritten.
Do not upload files to the server’s permanent filesystem until they have been fully validated.
As much as possible, use an established framework for preprocessing file uploads rather than attempting to write your own validation mechanisms.

Question 36

What is an XXE vulnerability?

Answer 36

XML external entity injection (also known as XXE) is a web security vulnerability that allows an attacker to interfere with an application’s processing of XML data.

XXE vulnerabilities arise because the XML specification contains various potentially dangerous features, and standard parsers support these features even if they are not normally used by the application.

• exploit XXE to retrieve files - where an external entity is defined containing the contents of a file, and returned in the application’s response.
• exploit XXe to perform SSRF attacks - where an external entity is defined based on a URL to a back-end system.
• blind XXE exfilitrate data out of band

Introduce (or edit) a DOCTYPE element that defines an external entity containing the path to the file.
Edit a data value in the XML that is returned in the application’s response, to make use of the defined external entity.

Question 37

How do you prevent XXE attacks?

Answer 37

You disable the dangerous XML features that are included in XML parsing libraries. Disable resolution of external entities and XInclude. This is usually done via configuration options.

Question 38

CSRF prevention

Answer 38

• [ ] Every request to the target server will include the cookie
  
  • [ ] Each time the server renders a page that includes sensitive actions, a unique CSRF token is passed to the user.
  • [ ] CSRF tokens can also be combined with other types of protective coding, including ensuring that session cookies are set with the SameSite cookie attribute. This attribute allows developers to instruct browsers to manage whether cookies are sent along with requests from third-party domains. - stateful
    
    • [ ] Generate once per user session or per request
    • [ ] Client sends it back as part of hidden form field, custom header, JSON payload
  • [ ] Double submit cookie - stateless
    
    • [ ] the site should generate a (ideally cryptographically strong) random value and set it as a cookie on the user’s machine separate from the session identifier. The site then requires that every transaction request includes this random value as a hidden form value, or in the request header.
    • [ ] In a nutshell, an attacker is unable to access the cookie value during a cross-site request. This prevents them from including a matching value in the hidden form value or as a request parameter/header.
    • [ ] Can also hash the CSRF cookie, so that an attacker cannot modify it
    • [ ] Custom request header
      
      • [ ] This defense relies on the browser’ssame-origin policy (SOP)restriction that only JavaScript can be used to add a custom header, and only within its origin.
      • [ ] By default, browsers do not allow JavaScript to make cross origin requests with custom headers.
  • [ ] Verify the origin with standard headers
  • [ ] Frameworks with built-in synchronizer tokens
    
    • [ ] For example, .NET hasbuilt-in protectionthat adds a token to CSRF vulnerable resources.
  • [ ] Remember that any Cross-Site Scripting (XSS) can be used to defeat all CSRF mitigation techniques!
  • [ ] Client side CSRF - attacker controlled input used to craft request from client’s browser
    
    • [ ] Bypasses same-site cookie attribute and CSRF tokens
    • [ ] Use input validation

Question 39

What is CORS?

Answer 39

CORS is a relaxation of the same origin policy. So if a request comes from the same origin then, the client can access the response. If it’s going to a different origin, it cannot access the response under SOP.

It can also define whether authenticated access is permitted using headers. the Access-Control-Allow-Credentials: true
This means that cross-origin requests can include cookies. This could be dangerous because authenticated responses with sensitive data can be accessed.

Access-Control-Allow-Methods - specify what methods to allow
Access-Control-Allow-Headers - specify what headers to allow
Access-Control-Allow-Origin - specify what origins to allow

Question 40

What is a CORS preflight request?

Answer 40

OPTION request

The browser sends the preflight request before the actual request message. The server must respond to the preflight request with information about the cross-origin requests the server’s willing to accept from the client URL.

he preflight response sometimes includes an additional Access-Control-Max-Age header. This metric specifies the duration (in seconds) for the browser to cache preflight results in the browser.

Question 41

What is clickjacking and how do you prevent it?

Answer 41

A malicious user builds a website and includes another site in an iframe. The attacker adds a transparent div on top of the iframe. The user is tricked into trying to click on what the site they see in the iframe, but actually clicks on something malicious like a malicious link.

To prevent:
Header that the server can specify. HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed></embed> or <object>
X-Frame-Options: deny
X-Frame-Options: sameorigin
X-Frame-Options: allow-from https://normal-website.com</object></frame>

CSP
frame-ancestors directive
‘self’ - like X-Frame-Options: sameorigin
‘none’ - like X-Frame-Options: deny
‘some website’

Question 42

What is a websocket?

Answer 42

WebSockets are a bi-directional, full duplex communications protocol initiated over HTTP. They are commonly used in modern web applications for streaming data and other asynchronous traffic.

Some modern web sites use WebSockets. WebSocket connections are initiated over HTTP and are typically long-lived. Messages can be sent in either direction at any time and are not transactional in nature. The connection will normally stay open and idle until either the client or the server is ready to send a message.

WebSockets are particularly useful in situations where low-latency or server-initiated messages are required, such as real-time feeds of financial data.

var ws = new WebSocket(“wss://normal-website.com/chat”);

The wss protocol establishes a WebSocket over an encrypted TLS connection, while the ws protocol uses an unencrypted connection.

ws.send(“Peter Wiener”);

To establish the connection, the browser and server perform a WebSocket handshake over HTTP.

In principle, WebSocket messages can contain any content or data format. In modern applications, it is common for JSON to be used to send structured data within WebSocket messages.

Question 43

What are some websocket security vulnerabilities?

Answer 43

User-supplied input transmitted to the server might be processed in unsafe ways, leading to vulnerabilities such as SQL injection or XML external entity injection.
Some blind vulnerabilities reached via WebSockets might only be detectable using out-of-band (OAST) techniques.
If attacker-controlled data is transmitted via WebSockets to other application users, then it might lead to XSS or other client-side vulnerabilities.

The majority of input-based vulnerabilities affecting WebSockets can be found and exploited by tampering with the contents of WebSocket messages.
i.e. sending {“message”:”<img></img>”}

cross-site websocket hijacking attack:
It arises when the WebSocket handshake request relies solely on HTTP cookies for session handling and does not contain any CSRF tokens or other unpredictable values.

An attacker can create a malicious web page on their own domain which establishes a cross-site WebSocket connection to the vulnerable application. The application will handle the connection in the context of the victim user’s session with the application.

Question 44

How do you secure a websocket connection?

Answer 44

Use the wss:// protocol (WebSockets over TLS).
Hard code the URL of the WebSockets endpoint, and certainly don’t incorporate user-controllable data into this URL.
Protect the WebSocket handshake message against CSRF, to avoid cross-site WebSockets hijacking vulnerabilities.
Treat data received via the WebSocket as untrusted in both directions. Handle data safely on both the server and client ends, to prevent input-based vulnerabilities such as SQL injection and cross-site scripting.

Question 45

How do you prevent insecure deserialization vulnerabilities?

Answer 45

Generally speaking, deserialization of user input should be avoided unless absolutely necessary.

Digital signature to check the integrity of the data

Question 46

What is web cache poisoning?

Answer 46

Web cache poisoning is an advanced technique whereby an attacker exploits the behavior of a web server and cache so that a harmful HTTP response is served to other users.

Fundamentally, web cache poisoning involves two phases. First, the attacker must work out how to elicit a response from the back-end server that inadvertently contains some kind of dangerous payload. Once successful, they need to make sure that their response is cached and subsequently served to the intended victims.

The cache sits between the server and the user, where it saves (caches) the responses to particular requests, usually for a fixed amount of time. If another user then sends an equivalent request, the cache simply serves a copy of the cached response directly to the user, without any interaction from the back-end. This greatly eases the load on the server by reducing the number of duplicate requests it has to handle.

Try to get a harmful response cached by the web server and have that response served to other users.

Question 47

What is an HTTP Host Header attack ?

Answer 47

The host header is user controllable. They could inject malicious input into the header.

Can lead to
Web cache poisoning
Business logic flaws in specific functionality
Routing-based SSRF
Classic server-side vulnerabilities, such as SQL injection

To prevent HTTP Host header attacks, the simplest approach is to avoid using the Host header altogether in server-side code. Double-check whether each URL really needs to be absolute. You will often find that you can just use a relative URL instead.
Validate the host header if used.
Whitelist permitted domains.

Question 48

What is HTTP Request Smuggling?

Answer 48

Usually associated with HTTP/1 requests, some websites that support HTTP/2 requests may still be vulnerable.

Most HTTP request smuggling vulnerabilities arise because the HTTP/1 specification provides two different ways to specify where a request ends: the Content-Length header and the Transfer-Encoding header.

The Content-Length header is straightforward: it specifies the length of the message body in bytes.
The Transfer-Encoding header can be used to specify that the message body uses chunked encoding. This means that the message body contains one or more chunks of data.

If the front-end and back-end servers behave differently in relation to the (possibly obfuscated) Transfer-Encoding header, then they might disagree about the boundaries between successive requests, leading to request smuggling vulnerabilities.

HTTP/2 end-to-end is immune.

Classic request smuggling attacks involve placing both the Content-Length header and the Transfer-Encoding header into a single HTTP/1 request and manipulating these so that the front-end and back-end servers process the request differently. The exact way in which this is done depends on the behavior of the two servers:

CL.TE: the front-end server uses the Content-Length header and the back-end server uses the Transfer-Encoding header.
TE.CL: the front-end server uses the Transfer-Encoding header and the back-end server uses the Content-Length header.
TE.TE: the front-end and back-end servers both support the Transfer-Encoding header, but one of the servers can be induced not to process it by obfuscating the header in some way.

Trick the server to bypass front end security controls.

You confuse the backend, so it serves the wrong responses to the wrong users.

Question 49

How do you prevent HTTP smuggling requests?

Answer 49

Use HTTP/2 end to end and disable HTTP downgrading if possible. HTTP/2 uses a robust mechanism for determining the length of requests and, when used end to end, is inherently protected against request smuggling. If you can’t avoid HTTP downgrading, make sure you validate the rewritten request against the HTTP/1.1 specification. For example, reject requests that contain newlines in the headers, colons in header names, and spaces in the request method.

Make the front-end server normalize ambiguous requests and make the back-end server reject any that are still ambiguous, closing the TCP connection in the process.

Never assume that requests won’t have a body. This is the fundamental cause of both CL.0 and client-side desync vulnerabilities.

Default to discarding the connection if server-level exceptions are triggered when handling requests.

If you route traffic through a forward proxy, ensure that upstream HTTP/2 is enabled if possible.

Question 50

JWT Security

Answer 50

Usually issues arise from flawed handling of JWTs within an application itself.

The signature is not verified properly. Sometimes applications don’t verify the signature at all and just decode the JWT.

Accepting a token with no signature. Set the alg value in the header to “none” and pass no signature. Sometimes the application will accept this instead of rejecting JWTs with no signature.

Need to keep server secret key a secret. Also need to use a secret key that is strong against brute-force attacks.

JWT header parameter injection:
There are user-controllable parameters each tell the recipient server which key to use when verifying the signature (jwk, jku, kid).

optional jwk header parameter, which servers can use to embed their public key directly within the token itself in JWK format. deally, servers should only use a limited whitelist of public keys to verify JWT signatures. However, misconfigured servers sometimes use any key that’s embedded in the jwk parameter.
You can exploit this behavior by signing a modified JWT using your own RSA private key, then embedding the matching public key in the jwk header.

some servers let you use the jku (JWK Set URL) header parameter to reference a JWK Set containing the key. When verifying the signature, the server fetches the relevant key from this URL.

Algorithm confusion attacks:
Algorithm confusion attacks (also known as key confusion attacks) occur when an attacker is able to force the server to verify the signature of a JSON web token (JWT) using a different algorithm than is intended by the website’s developers. If this case isn’t handled properly, this may enable attackers to forge valid JWTs containing arbitrary values without needing to know the server’s secret signing key.
Try to switch algorithms to get the verification to be done using a different algo and a forged key.

1. Obtain the server’s public key
2. Convert the public key to a suitable format
3. Create a malicious JWT with a modified payload and the alg header set to HS256.
4. Sign the token with HS256, using the public key as the secret.

Question 51

How do you prevent JWT vulnerabilities?

Answer 51

Use an up-to-date library for handling JWTs and make sure your developers fully understand how it works, along with any security implications.

Make sure that you perform robust signature verification on any JWTs that you receive, and account for edge-cases such as JWTs signed using unexpected algorithms.

Enforce a strict whitelist of permitted hosts for the jku header.

Make sure that you’re not vulnerable to path traversal or SQL injection via the kid header parameter.

Always set an expiration date for any tokens that you issue.

Avoid sending tokens in URL parameters where possible.

Include the aud (audience) claim (or similar) to specify the intended recipient of the token. This prevents it from being used on different websites.

Enable the issuing server to revoke tokens (on logout, for example).

Question 52

What are the same-site cookie attribute values mean?

Answer 52

None - cookies are sent on cross-site requests

Lax - cookies are sent on cross-site requests for safe requests (not POST) and must be top-level navigation (i.e. the URL changes in the browser). This is default for Chrome.

Strict - never sent on cross-site requests

Question 53

Oauth security

Answer 53

Always use CSRF token with the state parameter to ensure flow integrity
Always whitelist redirect URIs to ensure proper URI validations
Bind the same client to authorization grants and token requests with a client ID
For confidential clients, make sure the client secrets aren’t leaked. Don’t put a client secret in your app that’s distributed through an App Store!

state parameter is optional but needs to be set to a random value to prevent CSRF attacks.

Question 54

OpenID Connect

Answer 54

Oauth is just for authorization.
OIDC provides identity and authentication.

OIDC is a thin layer on top of Oauth 2.0 that adds functionality for login and profile info about the person who is logged in.

The only difference in the flow is that the scope query param in the request is set to openid.
The only difference is that when the client exchanges the authorization code, they get back an access token AND a id token.

The ID token is a JWT. The claims in the JWT has identity info about the user.

Question 55

Explain GraphQL security

Answer 55

Apply proper input validation checks on all incoming data.

Expensive queries will lead to Denial of Service (DoS), so add checks to limit or prevent queries that are too expensive.
Add depth limiting to incoming queries
Add amount limiting to incoming queries
Add pagination to limit the amount of data that can be returned in a single response
Add reasonable timeouts at the application layer, infrastructure layer, or both
Consider performing query cost analysis and enforcing a maximum allowed cost per query
Enforce rate limiting on incoming requests per IP or user (or both) to prevent basic DoS attacks
Implement the batching and caching technique on the server-side (Facebook’s DataLoader can be used for this)

Ensure that the API has proper access control checks.
Disable insecure default configurations (e.g. excessive errors, introspection, GraphiQL, etc.).

batching attacks - can make multiple queries in one request
- add rate limiting
- limit the number of queries that can be run at once

Disable introspection
This allows the consumer of your API to learn everything about your API, schemas, mutations, deprecated fields and sometimes unwanted “private fields”.

Question 56

What is SOAP?

Answer 56

SOAP (Simple Object Access Protocol) is a messaging protocol used for exchanging structured information between web services.
It uses XML for its message format and HTTP/SMTP for transport.

Question 57

What are some things you can do to secure SOAP web services?

Answer 57

Limit message sizes
Rate limiting
Validate payloads

Question 58

What is LDAP?

Answer 58

Allows you to search for someone/something where you don’t know where it is. Collects data from Active Directory, which contains user accounts.

Auth into Linux apps - Docker, Jenkins, etc.
May be used for standalone auth

Ultimate source of truth for identities

LDAP Injection is an attack used to exploit web based applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it’s possible to modify LDAP statements through techniques similar to SQL Injection.

Defense:
Escape all variables using the right LDAP encoding function
Use a framework (like LINQtoLDAP that escapes automatically.

Question 59

SAML SSO

Answer 59

Protocol for exchanging auth btw directories and apps

Service makes a SAML request to the idp. User logs in.
IDP issues a SAML token (XML) with info about the user.

SAML token gets sent to the browser. Browser sends the token to the service.

Service validates the XML token. Then grants the user access if validation is successful.

The SAML assertion is signed by the IDP. The service maps the user identifier in the SAML assertion to its own user store.

Always perform schema validation on the XML document prior to using it for any security-­related purposes:
Securely validate the digital signature: