OWASP

Question 1

DDOS

Answer 1

Disrupt normal traffic to a server, service, network.

Question 2

HTTP Flood - Layer 7 Attack

Answer 2

This attack is similar to pressing refresh in a web browser over and over on many different computers at once – large numbers of HTTP requests flood the server, resulting in denial-of-service. Comes from bot.

Question 3

SYN Flood - protocol attack

Answer 3

This attack exploits the TCP handshake by sending a target a large number of TCP “Initial Connection Request” SYN packets with spoofed source IP addresses. The target machine responds to each connection request and then waits for the final step in the handshake, which never occurs, exhausting the target’s resources in the process.

Question 4

DNS Flood - volumetric attack

Answer 4

A DNS Amplification is like if someone were to call a restaurant and say “I’ll have one of everything, please call me back and tell me my whole order,” where the callback phone number they give is the target’s number.

By making a request to an open DNS server with a spoofed IP address (the real IP address of the target), the target IP address then receives a response from the server. The attacker structures the request such that the DNS server responds to the target with a large amount of data. As a result, the target receives an amplification of the attacker’s initial query.

Question 5

DDoS mitigation

Answer 5

Rate limiting, WAF , black hole routing, anycast network diffusion (diffuse traffic within the network)

Question 6

A1 - Injection Attack

Answer 6

Attack Description
SQL, NoSQL, OS and LDAP injections
Untrusted data is sent as query or command
Execute command and access data without proper authorization
Where?
text box, u/pwd field, feedback/comment field, URL

select id from users where username=‘’ or 1=1# and password=‘”.md5($MD5PREFIX.$password).”’
Threat:SQL InjectionURL:/api/v1/auth(GET)Query String:?=%28select%20extractvalue%28xmltype%28%27%3c…Attempted on:URLThreat Pattern:stage-my.nutanix.com/api/v1/auth

Countermeasures - input sanitization, parameterized queries.

Question 7

A2 - Broken Authentication

Answer 7

Attack Description
Broken authentication occurs when the application mismanages session related information such that user’s identity gets compromised. 
Credential Stuffing 
Dictionary Attack
Default, weak or well-known passwords
Expose session ID’s in the URL 
Session hijacking 
Do not properly invalidate session ID’s after logout and inactivity 

Countermeasures

• MFA
• Enforce strict password policy
• Harden by using same message for all outcomes
• Session ID’s should not be in the URL. Session ID’s should be securely stored and invalidated after logout, idle and absolute timeout.

Question 8

A3 - Sensitive Data Exposure

Answer 8

Attackers can sniff the data if not handled securely

• Man in the middle attack
• Downgrading ciphers
• Weak encryption keys
• Weak TLS

Countermeasures

• Encrypt sensitive data in transit and at rest
• Disable caching of response with sensitive data. Hackers might get cached copies and steal information.

Question 9

A4 – XML External Entity (XXE)

Answer 9

Billion laughs
this small (< 1 KB) block of XML will actually contain 109= a billion "lol"s, taking up almost 3gigabytesof memory.[

Countermeasures

• Avoid serialization of sensitive data
• Implement whitelist to prevent malicious XML upload
• WAF block XXE

Question 10

A5 - Broken Access Control

Answer 10

Able to access restricted page, directory or database.

Countermeasures

• Invalidate token and cookies after logout
• Forced login/logout after a password change
• Server side resource restriction

Question 11

A6 – Security Misconfiguration

Answer 11

Security misconfigurations are weak passwords, default passwords, default scripts stored on the server, default error messages.

Web Server
DB Server

Hardening process for application 
Ensure defaults are all changed
Install only the required features from a framework
All servers – same config 
Repeatable process

Question 12

A7 – Cross Site Scripting (XSS)

Answer 12

Attack Description
Client side injection of untrusted data or scripts into a web page
Script gets executed in the browser.
Used to steal users data, deface websites.

Threat:Cross Site ScriptingURL:/samlsso(GET)Query String:?spEntityID=nutanix.portal.relayware.com%22%3e…Attempted on:request parameter spEntityIDThreat Pattern:spEntityID=nutanix.portal.relayware.com%22%3e%…

Countermeasures
Output encoding and escaping of untrusted characters
Enable Content-Security-Policy
modern browsers do not execute untrusted scripts

Question 13

A8 – Insecure Deserialization

Answer 13

Attack Description

Altering the serialized objects in the cookies for privilege escalation.

X:x:{z:z:”Name”:r:”User”} -> Normal cookie
X:x:{z:z :”Name”:r:”Admin”} -> Altered cookie object

Encryption of serialized data
Deserializers to run with least privileges

Question 14

X-Frame-Options: SAMEORIGIN

Answer 14

To allow request only from the same domain

ALLOW, DENY, SAMEORIGIN

Question 15

X-Content-Type-Options: nosniff

Answer 15

• browsers would try to guess the content type of a request using content sniffing

Question 16

HSTS (Http Strict Transport Security)

Answer 16

HSTS (Http Strict Transport Security) If you omit the https protocol, you are potentially vulnerable to Man in the Middle attacks

add the “Strict-Transport-Security” header to the response. For example the following would instruct the browser to treat the domain as an HSTS host for a year (there are approximately 31536000 seconds in a year):

Strict-Transport-Security: max-age=31536000 ; includeSubDomains

Question 17

HTTP Public Key Pinning (HPKP)

Answer 17

prevent Man In the Middle Attack with Forged Certificates.

HPKP can circumvent this threat for the HTTPS protocol by telling the client which public key belongs to a certain web server. HPKP is a Trust on First Use (TOFU) technique. The first time a web server tells a client via a special HTTP header which public keys belong to it, the client stores this information for a given period of time. When the client visits the server again, it expects a certificate containing a public key whose fingerprint is already known via HPKP. If the server delivers an unknown public key, the client should present a warning to the user.
present a warning to the user.
Public-Key-Pins-Report-Only: max-age=5184000 ; pin-sha256=”d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=” ; pin-sha256=”E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=” ; report-uri=”http://example.net/pkp-report” ; includeSubDomains

Question 18

Content Security Policy (CSP)

Answer 18

mitigate content injection vulnerabilities, such as cross-site scripting (XSS).
a web application can declare that it expects to load scripts from specific, trusted sources, by including the following header in the response:
Content-Security-Policy: script-src https://trustedscripts.example.com

Question 19

HTTP Caching - etag

Answer 19

ETag HTTP header to communicate a validation token.
The validation token enables efficient resource update checks: no data is transferred if the resource has not changed.

etag: W/”2462-1719a16d9a8”

Question 20

Http Security Headers

Answer 20

accept-ranges: bytes
cache-control: max-age=0, no-cache, no-store
content-encoding: gzip
content-length: 3536
content-security-policy: default-src 'none'; script-src 'self' 
content-type: text/html; charset=UTF-8
date: Sat, 25 Apr 2020 03:42:05 GMT
etag: W/"2462-1719a16d9a8"
expires: Sat, 25 Apr 2020 03:42:05 GMT
last-modified: Tue, 21 Apr 2020 00:15:21 GMT
pragma: no-cache
status: 200
strict-transport-security: max-age=31536000
vary: Accept-Encoding
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: DENY
x-xss-protection: 1; mode=block

Question 21

“no-cache” and “no-store”

Answer 21

always validate the cached response using etag.

no store - It simply disallows the browser and all intermediate caches from storing any version of the returned response

Question 22

“max-age”

Answer 22

This directive specifies the maximum time in seconds that the fetched response is allowed to be reused from the time of the request.

Question 23

Reverse Proxy

Answer 23

• Receiving a user connection request
• Completing a TCP three-way handshake, terminating the initial connection
• Connecting with the origin server and forwarding the original request

IP Masking - your origin server’s IP address is masked. This makes it considerably more difficult for attackers to gain access and launch direct-to-IP denial of service attacks.

Question 24

Forward proxy

Answer 24

outbound Block employees from visiting certain websites
Monitor employee online activity
Block malicious traffic from reaching an origin server
Improve the user experience by caching external site content

Question 25

SSL / TLS Certificate

Answer 25

ingle-name certificates that protect one subdomain, wildcard certificates that protect unlimited subdomains, and multi-domain certificates.

Question 26

Subject Alternate Name

Answer 26

SAN allows identities, such as an email address, DNS name, IP or URL to be bound to the subject of a certificate. This provides the ability to secure multiple domains with a single certificate.

Subject Alternate Name
DNS Name : *.nutanix.com
DNS Name :nutanix.com

Question 27

Extended Validation Certificate (EV)

Answer 27

EV certificates reassure users that they are viewing a website that is owned by the legal entity that purchased the SSL certificate, not an impostor site. The user’s browser displays a

green address bar containing the name of the legal entity to confirm the site’s validity.

Question 28

SSL Handshake

Answer 28

SSL Handshake
For an SSL/TLS connection to be established, the following process must take place:
1. At the TCP layer, the client sends a SYN (synchronize) packet to the server.
2. The server sends a SYN-ACK (synchronize-acknowledge) packet back to the client.
3. The client sends an ACK (acknowledge) packet to the server. Together with the ACK packet, an SSL/TLS client also sends a client hello message that includes cryptographic algorithms (cipher suites) and a random byte string.
4. The server responds with a ServerHello message containing the chosen cipher suite, a session ID, digital certificate and another random byte string. If required, the server issues a client certificate request containing the supported certificate types and CA names.
5. The client verifies the server’s certificate, and then sends a ClientKeyExchange – the random byte string used to create an encryption key. If necessary, the client also provides a private key and its own client certificate, or a warning that no certificate exists. Lastly the client sends a ChangeCipherSpec message to say that from here on, communication will be encrypted using the negotiated key and cipher suite.
6.The server responds with a ChangeCipherSpec message to confirm.
7.The client and server can now exchange requests and responses for the duration of the session. The messages are symmetrically encrypted by the secret key.