Notes on Cyber Security:

OWASP TOP 10

what is OWASP ?

OWASP: The Open Web Application Security Project is a nonprofit foundation focused on
understanding web technologies and exploitations and provides resources and tools
designed to improve the security of software applications.

OWASP’s core principles is that all of their materials be freely available and easily
accessible on their website, making it possible for anyone to improve their own web
application security. The materials they offer include documentation, tools, videos, and
forums. Perhaps their best-known project is the OWASP Top 10.

What is OWASP TOP 10 ?

The OWASP Top 10 is a regularly-updated report outlining security concerns for web
application security, focusing on the 10 most critical risks → ‘awareness document’ in order
to minimize and/or mitigate security risks.

1. Injection
2. Broken Authentication
3. Sensitive Data Exposure
4. XML External Entity
5. Broken Access Control
6. Security Misconfiguration
7. Cross-site Scripting
8. Insecure Deserialization
9. Components with Known Vulnerabilities
10. Insufficient Logging & Monitoring

1.INJECTION :

Injection flaws occur because user controlled input is interpreted as actual commands or
parameters by the application. Some common examples include:

SQL Injection: This occurs when user controlled input is passed to SQL queries. As a result,
an attacker can pass in SQL queries to manipulate the outcome of such queries.

Command Injection: This occurs when user input is passed to system commands. As a
result, an attacker is able to execute arbitrary system commands on application servers.

Command Injection occurs when server-side code (like PHP) in a web application makes a
system call on the hosting machine. Sometimes this won't always end in something
malicious, like a whoami or just reading of files. That isn't too bad. But the thing about
command injection is it opens up many options for the attacker. The worst thing they could
do would be to spawn a reverse shell to become the user that the web server is running as.
A simple nc -e /bin/bash is all that's needed and they own your server; some variants of
netcat (reading from and writing to network connections using TCP or UDP) don't support
the -e option. You can use a list of these reverse shells as an alternative.
A reverse shell is a type of shell where the target machine (the victim) initiates an outbound
connection to an attacker’s machine. This is in contrast to a bind shell, where the target
machine opens a listening port, and the attacker connects to it. Reverse shells are often
used in penetration testing or cyberattacks because they can bypass firewalls and network
security measures more easily.

How a Reverse Shell Works:

1. Victim Machine (Target): The victim's machine opens a connection back to a
predefined IP address (usually the attacker's machine) and port.
2. Attacker’s Machine (Listener): The attacker has a listener set up on their machine
to accept the incoming connection.
3. Once the connection is established, the attacker can run commands on the victim’s
machine as if they were logged into the shell directly.

If an attacker is able to successfully pass input that is interpreted correctly, they would be
able to do the following:

-Access, Modify and Delete information in a database when this input is passed into
database queries. This would mean that an attacker can steal sensitive information such as
personal details and credentials.

-Execute Arbitrary system commands on a server that would allow an attacker to gain
access to users’ systems. This would enable them to steal sensitive data and carry out more
attacks against infrastructure linked to the server on which the command is executed.

The main defense for preventing injection attacks is ensuring that user controlled input is not
interpreted as queries or commands. There are different ways of doing this:

Using an allow list: when input is sent to the server, this input is compared to a list of safe
input or characters. If the input is marked as safe, then it is processed. Otherwise, it is
rejected and the application throws an error.

Stripping input: If the input contains dangerous characters, these characters are removed
before they are processed.

Dangerous characters or input is classified as any input that can change how the underlying
data is processed. Instead of manually constructing allow lists or even just stripping input,
there are various libraries that perform these actions for you. (Bleach python, DOMpurify js..)

*nc -e /bin/bash command can be used to create remote shells (reverse or bind) and is
often seen in penetration testing and malicious hacking activities

*cd /etc/passwd users in linux system

*whoami command displays the username of the current user.

*getent /etc/passwd get user details : getent /etc/passwd www-data to get the user
shell

*lsb_release -a ubuntu version

2. BROKEN AUTHENTIFICATION :

A user would enter these credentials, the server would verify them. If they are correct, the
server would then provide the users’ browser with a session cookie. A session cookie is
needed because web servers use HTTP(S) to communicate which is stateless.

If an attacker is able to find flaws in an authentication mechanism, they would then

successfully gain access to other users’ accounts. Some common flaws in authentication
mechanisms include:

-Brute force attacks: If a web application uses usernames and passwords, an attacker is
able to launch brute force attacks that allow them to guess the username and passwords
using multiple authentication attempts.

-Use of weak credentials: web applications should set strong password policies. If
applications allow users to set passwords such as ‘password1’ or common passwords, then
an attacker is able to easily guess them and access user accounts.

-Weak Session Cookies: Session cookies are how the server keeps track of users. If session
cookies contain predictable values, an attacker can set their own session cookies and
access users’ accounts.

There can be various mitigation for broken authentication mechanisms depending on the
exact flaw:

-To avoid password guessing attacks, ensure the application enforces a strong password
policy.

-To avoid brute force attacks, ensure that the application enforces an automatic lockout after
a certain number of attempts: limiting or delaying repeated login attempts using rate limiting.

-Implement Multi Factor Authentication - If a user has multiple methods of authentication, for
example, using username and passwords and receiving a code on their mobile device, then
it would be difficult for an attacker to get access to both credentials to get access to their
account.

3. SENSITIVE DATA EXPOSURE :

When a web app accidentally divulges sensitive data, we refer to it as "Sensitive Data
Exposure". This is often data directly linked to customers (e.g. names, dates-of-birth,
financial information, etc), but could also be more technical information, such as usernames
and passwords. At more complex levels this often involves techniques such as a "Man in
The Middle Attack", whereby the attacker would force user connections through a device
which they control, then take advantage of weak encryption on any transmitted data to gain
access to the intercepted information (if the data is even encrypted in the first place...)

MITM Attack:

Client ↔ Attacker ↔ Website (attacker can monitor and alter the communication).

*flat-file databases are stored as a file on the disk of a computer. Usually this would not be a
problem for a web app, but what happens if the database is stored underneath the root
directory of the website (i.e. one of the files that a user connecting to the website is able to
access)? Well, we can download it and query it on our own machine, with full access to
everything in the database. Sensitive Data Exposure indeed!

The most common (and simplest) format of flat-file database is an sqlite database. These
can be interacted with in most programming languages, and have a dedicated client for
querying them on the command line. This client is called "sqlite3", and is installed by default
on Kali.

access db via cli sqlite3 +dbname and see data with sql command

*Crackstation: good at cracking weak password hashes. For more complicated hashes we
would need more sophisticated tools; weak MD5 hashes: Message Digest 5 (MD5) is a
cryptographic hash function that takes any input and produces a 128-bit hexadecimal
number.

*file webapp.db download database file to know what type it is (example sqlite)

Data exposure risk can be minimized by encrypting all sensitive data as well as disabling the
caching of any sensitive information. Additionally, web application developers should take
care to ensure that they are not unnecessarily storing any sensitive data.

4. XML EXTERNAL ENTITY :

An XML External Entity (XXE) attack is a vulnerability that abuses features of XML
parsers/data. It often allows an attacker to interact with any backend or external systems that
the application itself can access and can allow the attacker to read the file on that system.
They can also cause Denial of Service (DoS) attack or could use XXE to perform
Server-Side Request Forgery (SSRF) inducing the web application to make requests to
other applications. XXE may even enable port scanning and lead to remote code execution.

There are two types of XXE attacks: in-band and out-of-band (OOB-XXE).

1) An in-band XXE attack is the one in which the attacker can receive an immediate
response to the XXE payload.

2) out-of-band XXE attacks (also called blind XXE), there is no immediate response from the
web application and attacker has to reflect the output of their XXE payload to some other file
or their own server.
*XML: Extensible Markup Language is a markup language that defines a set of rules for
encoding documents in a format that is both human-readable and machine-readable

Why we use XML?

1. XML is platform-independent and programming language independent, thus it can be

used on any system and supports the technology change when that happens.

2. The data stored and transported using XML can be changed at any point in time without
affecting the data presentation.

3. XML allows validation using DTD ( Document Type Definition) and Schema. This
validation ensures that the XML document is free from any syntax error.

4. XML simplifies data sharing between various systems because of its platform-independent
nature. XML data doesn’t require any conversion when transferred between different
systems.

The best ways to prevent XEE attacks are to have web applications accept a less complex
type of data, such as JSON**, or at the very least to patch XML parsers and disable the use
of external entities in an XML application.

**JavaScript Object Notation (JSON) is a type of simple, human-readable notation often

used to transmit data over the internet. Although it was originally created for JavaScript,
JSON is language-agnostic and can be interpreted by many different programming
languages.

5. BROKEN ACCESS CONTROL :

Websites have pages that are protected from regular visitors, for example only the site's
admin user should be able to access a page to manage other users. If a website visitor is
able to access the protected page/pages that they are not authorized to view, the access
controls are broken.

A regular visitor being able to access protected pages, can lead to the following:
Being able to view sensitive information
Accessing unauthorized functionality

OWASP have a listed a few attack scenarios demonstrating access control weaknesses:
-Scenario #1: The application uses unverified data in a SQL call that is accessing account
information:

pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );

An attacker simply modifies the ‘acct’ parameter in the browser to send whatever account
number they want. If not properly verified, the attacker can access any user’s account.
http://example.com/app/accountInfo?acct=notmyacct

Scenario #2: An attacker simply force browses to target URLs. Admin rights are required for
access to the admin page.
http://example.com/app/getappInfo
—> To put simply, broken access control allows attackers to bypass authorization which can
allow them to view sensitive data or perform tasks as if they were a privileged user.

IDOR, or Insecure Direct Object Reference, is the act of exploiting a misconfiguration in the
way user input is handled, to access resources you wouldn't ordinarily be able to access.
IDOR is a type of access control vulnerability.

For example, let's say we're logging into our bank account, and after correctly authenticating
ourselves, we get taken to a URL like this
https://example.com/bank?account_number=1234. On that page we can see all our
important bank details, and a user would do whatever they needed to do —-> a hacker may
be able to change the account_number parameter to something else like 1235, and if the
site is incorrectly configured, then he would have access to someone else's bank
information.

Broken access controls allow attackers to bypass authorization and perform tasks as though
they were privileged users such as administrators

Access controls can be secured by ensuring that a web application uses authorization
tokens and sets tight controls on them.

6. SECURITY MISCONFIGURATION :

Security misconfigurations include:

–Poorly configured permissions on cloud services, like S3 buckets

–Having unnecessary features enabled, like services, pages, accounts or privileges

–Default accounts with unchanged passwords

–Error messages that are overly detailed and allow an attacker to find out more about the
system

–Not using HTTP security headers, or revealing too much detail in the Server: HTTP header

7. CROSS SITE SCRIPTING :

Cross-site scripting, also known as XSS is a security vulnerability typically found in web
applications. It’s a type of injection which can allow an attacker to execute malicious scripts
and have it execute on a victim’s machine.

This vulnerability can be exploited to run malicious JavaScript code on a victim’s browser.

For example, an attacker could send an email to a victim that appears to be from a trusted
bank, with a link to that bank’s website. This link could have some malicious JavaScript code
tagged onto the end of the url. If the bank’s site is not properly protected against cross-site
scripting, then that malicious code will be run in the victim’s web browser when they click on
the link.

A web application is vulnerable to XSS if it uses unsanitized user input. XSS is possible in
Javascript, VBScript, Flash and CSS. There are three main types of cross-site scripting:

-Stored XSS - the most dangerous type of XSS. This is where a malicious string originates
from the website’s database. This often happens when a website allows user input that is not
sanitized (remove the "bad parts" of a users input) when inserted into the database.

-Reflected XSS - the malicious payload is part of the victims request to the website. An
attacker needs to trick a victim into clicking a URL to execute their malicious payload.

-DOM-Based XSS -It represents the page so that programs can change the document
structure, style and content. A web page is a document and this document can be either
displayed in the browser window or as the HTML source.

*In javascript, window.location.hostname returns the domain name of the web host.
Therefore we can use this js payload to display our IP considering the information provided
in the hints. <script>alert(window.location.hostname)</script> : reflected xss

*Use this payload to obtain cookies <script>alert(document.cookies)</script>

Mitigation strategies for cross-site scripting include escaping untrusted HTTP requests as
well as validating and/or sanitizing user-generated content. Using modern web development
frameworks like ReactJS and Ruby on Rails also provides some built-in cross-site scripting
protection.

8. INSECURE DESERIALIZATION :

Insecure deserialization is replacing data processed by an application with malicious code;

allowing anything from DoS (Denial of Service) to RCE (Remote Code Execution) that the
attacker can use to gain a foothold in a pentesting scenario.

Specifically, this malicious code leverages the legitimate serialization and deserialization
process used by web applications.

Serialisation is the process of converting objects used in programming into simpler,

compatible formatting for transmitting between systems or networks for further processing or
storage.

Alternatively, deserialisation is the reverse of this; converting serialised information into their
complex form - an object that the application will understand.

Say you have a password of "password123" from a program that needs to be stored in a
database on another system. To travel across a network this string/output needs to be
converted to binary. Of course, the password needs to be stored as "password123" and not
its binary notation. Once this reaches the database, it is converted or deserialised back into
"password123" so it can be stored.

Simply, insecure deserialization occurs when data from an untrusted party (I.e. a hacker)
gets executed because there is no filtering or input validation; the system assumes that the
data is trustworthy and will execute it no holds barred.

*Cookies are not permanent storage solutions like databases. Some cookies such as
session ID's will clear when the browser is closed, others, however, last considerably longer.
This is determined by the "Expiry" timer that is set when the cookie is created.

Secure cookies work over https (attribute SecureOnly in cookie)

An insecure deserialization attack is like having the movers tamper with the contents of the
boxes before they are unpacked.

An insecure deserialization exploit is the result of deserializing data from untrusted sources,
and can result in serious consequences like DDoS attacks and remote code execution
attacks. While steps can be taken to try and catch attackers, such as monitoring
deserialization and implementing type checks, the only sure way to protect against insecure
deserialization attacks is to prohibit the deserialization of data from untrusted sources.

9. COMPONENTS WITH KNOWN VULNERABILITIES :

Many modern web developers use components such as libraries and frameworks in their
web applications. These components are pieces of software that help developers avoid
redundant work and provide needed functionality; common example include front-end
frameworks like React and smaller libraries that used to add share icons or a/b testing.
Some attackers look for vulnerabilities in these components which they can then use to
orchestrate attacks. Some of the more popular components are used on hundreds of
thousands of websites; an attacker finding a security hole in one of these components could
leave hundreds of thousands of sites vulnerable to exploit.

For example, let's say that a company hasn't updated their version of WordPress for a few
years, and using a tool such as wpscan, you find that it's version 4.6. Some quick research
will reveal that WordPress 4.6 is vulnerable to an unauthenticated remote code
execution(RCE) exploit, and even better you can find an exploit already made on exploit-db.

10. INSUFFICIENT LOGGING AND MONITORING :

OWASP recommends that web developers should implement logging and monitoring as well
as incident response plans to ensure that they are made aware of attacks on their
applications.

The information stored in logs should include:

HTTP status codes

Time Stamps
Usernames
API endpoints/page locations
IP addresses

These logs do have some sensitive information on them so its important to ensure that logs
are stored securely and multiple copies of these logs are stored at different locations.
As you may have noticed, logging is more important after a breach or incident has occurred.
The ideal case is having monitoring in place to detect any suspicious activity. The aim of
detecting this suspicious activity is to either stop the attacker completely or reduce the
impact they've made if their presence has been detected much later than anticipated.
Common examples of suspicious activity includes:

–multiple unauthorized attempts for a particular action (usually authentication attempts or

access to unauthorized resources e.g. admin pages)
–requests from anomalous IP addresses or locations: while this can indicate that someone
else is trying to access a particular user's account, it can also have a false positive rate.
–use of automated tools: particular automated tooling can be easily identifiable e.g. using the
value of User-Agent headers or the speed of requests. This can indicate an attacker is using
automated tooling.
–common payloads: in web applications, it's common for attackers to use Cross Site
Scripting (XSS) payloads. Detecting the use of these payloads can indicate the presence of
someone conducting unauthorised/malicious testing on applications.

Just detecting suspicious activity isn't helpful. This suspicious activity needs to be rated
according to the impact level. For example, certain actions will higher impact than others.
These higher impact actions need to be responded to sooner thus they should raise an
alarm which raises the attention of the relevant party.
other notes:
● The Domain Name System (DNS) is the phonebook of the Internet. DNS translates
domain names to IP addresses so browsers can load Internet resources.
DNS spoofing/cache poisoning: This is an attack where forged DNS data is introduced into a
DNS resolver’s cache, resulting in the resolver returning an incorrect IP address for a
domain. Instead of going to the correct website, traffic can be diverted to a malicious
machine or anywhere else the attacker desires; often this will be a replica of the original site
used for malicious purposes such as distributing malware or collecting login information.

DNS hijacking: In DNS hijacking, the attacker redirects queries to a different domain name
server. This can be done either with malware or with the unauthorized modification of a DNS
server. Although the result is similar to that of DNS spoofing, this is a fundamentally different
attack because it targets the DNS record of the website on the nameserver, rather than a
resolver’s cache.

● session cookies, tokens

 ● Man in the middle attack
Common Methods of MITM Attacks:

Wi-Fi Eavesdropping:
Attackers set up a fake Wi-Fi access point (often called an "evil twin") that looks like a
legitimate network. Once users connect to this malicious network, the attacker can intercept
their communications.

DNS Spoofing:
The attacker redirects the victim to a malicious website instead of the legitimate one by
corrupting the domain name system (DNS) queries. The user may unknowingly enter
sensitive information on the fake website, which the attacker collects.

IP Spoofing:
The attacker pretends to be a trusted device by forging the IP address. This allows the
attacker to intercept and manipulate communications between the victim and the legitimate
system.

HTTPS Spoofing (SSL Stripping):

The attacker downgrades a secure HTTPS connection to an unencrypted HTTP connection
by removing the SSL layer, exposing sensitive data that was supposed to be protected.

Session Hijacking:
After a user logs into a website, the attacker steals the session token (often stored in
cookies). The attacker then uses this token to impersonate the victim and gain unauthorized
access to their account.

Email Hijacking:
Attackers can gain access to email accounts and monitor communications, especially in
businesses. They can manipulate email conversations, redirect funds, or steal sensitive
information.