OWASP Flashcards Preview

Cryptography > OWASP > Flashcards

Flashcards in OWASP Deck (28)
Loading flashcards...
1

DDOS

Disrupt normal traffic to a server, service, network.

2

HTTP Flood - Layer 7 Attack

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.

3

SYN Flood - protocol attack

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.

4

DNS Flood - volumetric attack

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.

5

DDoS mitigation

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

6

A1 - Injection Attack

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($MD5_PREFIX.$password).”’
Threat:SQL Injection  URL:/api/v1/auth(GET)Query String:?_=%28select%20extractvalue%28xmltype%28%27%3c... Attempted on:URL Threat Pattern:stage-my.nutanix.com/api/v1/auth

Countermeasures - input sanitization, parameterized queries.

7

A2 - Broken Authentication

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.

8

A3 - Sensitive Data Exposure

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.

9

A4 – XML External Entity (XXE)

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

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

10

A5 - Broken Access Control

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

11

A6 – Security Misconfiguration

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

12

A7 – Cross Site Scripting (XSS)

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 spEntityID Threat 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

13

A8 – Insecure Deserialization

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

14

X-Frame-Options: SAMEORIGIN

To allow request only from the same domain
ALLOW, DENY, SAMEORIGIN

15

X-Content-Type-Options: nosniff

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

16

HSTS (Http Strict Transport Security)

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

17

HTTP Public Key Pinning (HPKP)

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

18

Content Security Policy (CSP)

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

19

HTTP Caching - etag

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"

20

Http Security Headers

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

21

"no-cache" and "no-store"

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

22

"max-age"

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

23

Reverse Proxy

-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.

24

Forward proxy

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

25

SSL / TLS Certificate

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

26

Subject Alternate Name

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

27

Extended Validation Certificate (EV)

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.

28

SSL Handshake

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.