Classification of Actors
First Party 1P – is knowingly and intentionally present in a conversation
Second Party 2P – is knowingly and intentionally involved but not participating or present
Third Party 3P - is unknowingly and unintentionally present in a conversation
Fourth Party 4P – is 3P of 3P
Properties of a Secure Channel
Confidentiality – Messages can’t be read by a 3rd party (3P)
Message Integrity – Messages can’t be unknowingly modified by 3P
Sender Authenticity – Valid messages creatable only by a 1P actor
Hashing vs. Encryption

Encryption scrambles data that can be decoded with a key. The intent is to pass the
information to another party, and the recipient will use keys to decipher the data.

Hashing also scrambles data, but the intent is to prove its authenticity. Administrators
can run a check on hashed data to determine the contents haven't been touched or
altered while in storage. No deciphering key exists.
Both methods involve shielding something sensitive from prying eyes. But clearly, they have
different goals and core functions.
Link: https://www.okta.com/identity-101/hashing-vsencryption/#:~:text=Consider%20these%20basic%20definitions%3A,is%20to%20prove%20its%
20authenticity.
Diffie Hellman Key Exchange
https://www.aleksandrhovhannisyan.com/blog/modular-arithmetic-and-diffie-hellman/
What Is a Rootkit?
A rootkit is a clandestine computer program designed to provide continued privileged access to
a computer while actively hiding its presence. The term rootkit is a connection of the two words
"root" and "kit." Originally, a rootkit was a collection of tools that enabled administrator-level
access to a computer or network. Root refers to the Admin account on Unix and Linux systems,
and kit refers to the software components that implement the tool.
OSI:
7. Application layer
6. Presentation layer
5. Session layer
4. Transport layer
3. Network layer
2. Data link layer
1. Physical layer
What is CIDR?
Classless Inter-Domain Routing (CIDR) is an IP address allocation method that improves data
routing efficiency on the internet.
L1/L2/L3
Hubs are L1 devices – Packet comes in, packet goes out
Switches are L2 devices – (a) Dispatch packets via MAC address (b) L3 switches are common
but are not what we’re talking about
Routers are L3 devices – (a) Dispatch packet via IP address (b) Lost of things called “routers”
aren’t actually routers (but some are)
ARP Protocol
Address Resolution Protocol allows hosts to map IP with MAC addresses.



ARP Announcements
ARP Probe
L2 Default gateway – The host to send to if not on local n/w
ARP Poisoning/Spoofing
Can be used to – (a) DoS another client (b) Cause n/w thrashing (c) Intercept traffic
Sticky MAC can be used to defend against ARP attacks. Sticky MAC ensures 1 physical port = 1
MAC address
Firewall
A firewall is a generic name for a network-level defense tactic that blindly applies a rulebased policy to network traffic.

Layer 3 firewalls (i.e. packet filtering firewalls) filter traffic based solely on
source/destination IP, port, and protocol.

Layer 4 firewalls do the above, plus add the ability to track active network connections,
and allow/deny traffic based on the state of those sessions (i.e. stateful packet
inspection).

Layer 7 firewalls (i.e. application gateways) can do all of the above, plus include the
ability to intelligently inspect the contents of those network packets. For instance, a
Layer 7 firewall could deny all HTTP POST requests from Chinese IP addresses. This
level of granularity comes at a performance cost, though.
Firewall implementation
Blacklisting traffic: Match rule? BLOCK
Whitelisting traffic: Match rule? ALLOW
There is always a default action if doesn’t match a specific rule.
Firewall rules are directional.
Network-based:
Some firewalls are network-based and run as its own device in front of many devices. PRO:
Single point management. CON: Complex rules for complex networks.
Host-based:
Some firewalls are host-based and run on each individual device for itself. PRO: Devices can
have different rule sets. CON: More to manage and update.
Most network devices have some sort of built-in firewall.
All standard OSes have built-in firewalls.
Linux – iptables/ UFW/ pf/ nftables
Windows – Windows Firewall
macOS – Firewall
IoT and embedded devices often lack firewalls. They rely on network-level firewalls.
Intrusion Detection System (IDS)
An IDS is a network monitoring component that is able to watch for signs of maliciousness.



Capable of granular and complex rules
o beyond L3/L4 headers
o Deep Packet Inspection (DPI)
Capable of pattern/regex matching
Capable of searching for multi-flow patterns
Example when is the tool optimal to use compared to other tools:
For an organization that can tolerate exposure for a short time but cannot bear rejection of
desirable traffic at all may have a negative impact on the organization. In such a case, IDS is
more appropriate.
Intrusion Prevention System (IPS)
An IPS is a type of IDS which is able to actively block maliciousness when found.



Capable of granular and complex rules
o beyond L2/L3 (TCP/IP) headers
o Deep Packet Inspection (DPI)
Capable of pattern/regex matching
Capable of searching for multi-flow patterns
Example when is the tool optimal to use compared to other tools:
An IPS does offer more protection because it acts automatically, leaving little time for an
attacker to continue compromising an organization. This may be appropriate for the sensitive
wings of the government that deal with confidential and sensitive information where
compromises, even for a small time, are not acceptable.
On the other hand, for an organization that can tolerate exposure for a short time but cannot
bear rejection of desirable traffic at all may have negative impact on the organization. In such a
case, IDS is more appropriate.
DoS
DoS is a type of attack which attempts to prevent legitimate users from accessing a service. The
attacker floods traffic.




Come in many different varieties
Usually uses shared Internet infrastructure
Traffic Floods
Usually based on an asymmetric tradeoff that favors the attacker
o Attacker’s cost is very small but defender’s cost is very high
Reflection Attacks
Reflection attacks are a type of network attack where the traffic is bounced through a third-party
in order to hide its source.


Usually relies on forging the source IP
o Causes the 3P to send traffic to the victim
Victim can block the source-IP (bouncing server) but never see the actual attacker
Amplification Attacks
Amplification attacks are a type of reflection attacks where the victim receives more traffic than
the attacker sends.


DDoS
Obvious asymmetry
DNS is a common vector for them
o Request: 10s of bytes
o Response: 100s of bytes
DDoS is a type of DoS attack where the source of the attack is distributed across the Internet.


Often accomplished via botnets
Each bot under the attacker’s control contributes negligible amount of traffic but the sum
is not negligible.
What is Mirai?
Mirai is malware that infects smart devices that run on ARC processors, turning them
into a network of remotely controlled bots or "zombies". This network of bots, called
a botnet, is often used to launch DDoS attacks.
Malware, short for malicious software, is an umbrella term that includes computer
worms, viruses, Trojan horses, rootkits and spyware.
In September 2016, the authors of the Mirai malware launched a DDoS attack on the
website of a well-known security expert. A week later they released the source code into
the world, possibly in an attempt to hide the origins of that attack. This code was quickly
replicated by other cybercriminals, and is believed to be behind the massive attack that
brought down the domain registration services provider, Dyn, in October 2016.
How does Mirai work?
Mirai scans the Internet for IoT devices that run on the ARC processor. This processor
runs a stripped-down version of the Linux operating system. If the default usernameand-password combo is not changed, Mirai is able to log into the device and infect it.
IoT, short for Internet of Things, is just a fancy term for smart devices that can connect
to the Internet. These devices can be baby monitors, vehicles, network routers,
agricultural devices, medical devices, environmental monitoring devices, home
appliances, DVRs, CC cameras, headset, or smoke detectors.
The Mirai botnet employed a hundred thousand hijacked IoT devices to bring down
Dyn.
Who were the creators of the Mirai botnet?
Twenty-one-year-old Paras Jha and twenty-year-old Josiah White co-founded Protraf
Solutions, a company offering mitigation services for DDoS attacks. Theirs was a classic
case of racketeering: Their business offered DDoS mitigation services to the very
organizations their malware attacked.
Why does the Mirai malware remain dangerous?
The Mirai is mutating.
Though its original creators have been caught, their source code lives on. It has given
birth to variants such as the Okiru, the Satori, the Masuta and the PureMasuta. The
PureMasuta, for example, is able to weaponize the HNAP bug in D-Link devices. The
OMG strain, on the other hand, transforms IoT devices into proxies that allow
cybercriminals to remain anonymous.
There is also the recently discovered - and powerful - botnet, variously nicknamed
IoTrooper and Reaper, which is able to compromise IoT devices at a much faster rate
than Mirai. The Reaper is able to target a larger number of device makers, and has far
greater control over its bots.
What are the various botnet models?
Centralized botnets
If you think of a botnet as a theatrical play, the C&C (Command and Control Server, also
known as the C2) server is its director. The actors in this play are the various bots that
have been compromised by malware infection, and made part of the botnet.
When the malware infects a device, the bot send out timed signals to inform the C&C
that it now exists. This connection session is kept open till the C&C is ready to command
the bot to do its bidding, which can include sending out spam, password cracking, DDoS
attacks, etc.
In a centralized botnet, the C&C is able to convey commands directly to the bots.
However, the C&C is also a single point of failure: If taken down, the botnet becomes
ineffective.
Tiered C&Cs
Botnet control may be organized in multiple tiers, with multiple C&Cs. Groups of
dedicated servers may be designated for a specific purpose, for example, to organize
the bots into subgroups, to deliver designated content, and so on. This makes the
botnet harder to take down.
Decentralized botnets
Peer-to-peer (P2P) botnets are the next generation of botnets. Rather than
communicate with a centralized server, P2P bots act as both a command server, and a
client which receives commands. This avoids the single point of failure problem inherent
to centralized botnets. Because P2P botnets operate without a C&C, they are harder to
shut down. Trojan.Peacomm and Stormnet are examples of malware behind P2P
botnets.
How does malware turn IoT devices into bots or zombies?
In general, email phishing is a demonstrably effective way of infecting the computer the victim is tricked into either clicking a link that points to a malicious website, or
downloading infected attachment. Many times the malicious code is written in such a
way that common antivirus software is not able to detect it.
In the case of Mirai, the user doesn’t need to do much beyond leaving the default
username and password on a newly installed device unchanged.
DoS Defenses
CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart)
Extra material on DoS:
Different DoS attacks have different methods of execution. The most common types are:
UDP flood exploits targets with User Datagram Protocol (UDP) packets, overwhelming it with
traffic and causing it to crash.
TCP SYN floods exploit the three-way handshake process used by TCP to establish a
connection between two devices. The attacker sends SYN packets to the target, which
responds with a SYN-ACK packet. The attacker does not respond with a third ACK packet,
causing the server to hold the connection open and eventually run out of resources.
HTTP flood sends HTTP requests to web servers, overwhelming it and causing it to crash or
become unresponsive.
Ping flood attacks assets with ICMP (Internet Control Message Protocol) Echo Request
packets, consuming all the bandwidth and making it impossible for legitimate traffic to get
through.
DoS attacks can have a significant impact on businesses and individuals, both in terms of
financial losses and damage to brand reputation. Some of the consequences of a successful
DoS attack may include:
A DoS attack can make a website or service unavailable to legitimate users, causing lost
revenue and damage to customer relationships.
Sites may remain online during a DoS attack. They may become slow or unresponsive, making
it difficult or impossible for users to interact.
The aftermath of a DoS attack can be expensive. Extensive damage can be done to the target
or legal fees may be incurred.
A successful DoS attack can damage a company's reputation, especially if it results in extended
downtime or data breaches.
IT staff, focused on DoS mitigation, can be a diversion from other attacks, and take time away
from projects and tasks.
Detecting a DoS attacks early is crucial in minimizing its impact. Indicators that a DoS attack
may be underway include:
Abnormally high traffic
Slow or unresponsive servers
High server utilization
Unusual traffic patterns
Unusual traffic sources
How can denial-of-service attacks be prevented?
Preventing a DoS attack can be challenging, but there are several effective techniques:
Network segmentation - Segmenting networks into smaller, more manageable pieces, can limit
the impact of a DoS attack. This can be done by creating VLANs, and firewalls can limit the
spread of an attack. The optimal solution is zero trust microsegmentation. Adding device-level
and device-cloaking firewalling, external to the operating system remains the most reliable form
of DoS protection.
Load balancing - Distributing traffic across multiple servers, a DoS attack can be prevented from
overwhelming a single server or resource. Load balancing can be achieved using hardware or
software solutions.
IP blocking - Blocking traffic from known or suspected malicious sources can prevent DoS traffic
from reaching its target.
Rate limiting - Limiting the rate of traffic to reach a server or resource can prevent a DoS attack
from overwhelming it.
Content Delivery Networks (CDNs) - Distributing website content across multiple locations
makes it more difficult for an attack to bring down an entire site.
What are horizontal or vertical scans?
Horizontal Scan - A horizontal scan is described as scan against a group of IPs for a single
port.
Vertical Scan - A vertical scan is described as a single IP being scanned for multiple ports.
Box Scanning - A combination of both vertical and horizontal scans.
How does the Web work?
The web is an array of protocols, standards, and un-written conventions for providing content
via the Internet.
What can the Web do?
The web was NOT built to serve:




In a secure way
In a private way
In a safe way
In a trustworthy way
Directory traversal
It is also known as path traversal or directory climbing, is a vulnerability in a web application
server caused by a HTTP exploit. The exploit allows an attacker to access restricted directories,
execute commands, and view data outside of the web root folder where application content is
stored.
What are the Risks of Directory Traversal?
Directory traversal poses three significant threats to the security and integrity of web servers
and applications:

Directory traversal can lead to unauthorized access of sensitive information stored in
files outside of the web root directory. This could include: system files, configuration files,
or even user data. The unauthorized access of confidential data is a direct breach of
privacy and can lead to information theft.

Attackers can read and also modify or delete critical files, causing serious system
malfunctions or service disruptions. This can lead to significant downtime, loss of
productivity, and even financial loss.

Successful directory traversal attacks can provide attackers with the ability to carry out
damaging attacks. For instance, gaining access to certain system files can provide
valuable information about the server’s structure, configuration, and the security
measures that are in place. Taken together, this is information that can be used to
construct more sophisticated attacks in the future.
Directory traversal is a serious security risk that can lead to the compromise of privacy, integrity,
and availability of web servers and applications.
Tools Used by Attackers to Locate Directory Traversal Vulnerabilities
Threat actors use a variety of tools to identify directory traversal vulnerabilities in web servers
and applications. Here are some of the most commonly used:
1. Burp Suite: This is a comprehensive web application security testing platform. It
includes a variety of tools, including a scanner that can automatically detect directory
traversal and other common vulnerabilities. Its Intruder tool can also be used to test for
traversal vulnerabilities manually.
2. OWASP ZAP (Zed Attack Proxy): This is a free, open-source web application security
scanner developed by the Open Web Application Security Project (OWASP). It can
identify a wide range of vulnerabilities, including directory traversal.
3. Nikto: A server scanner that checks servers for dangerous files, outdated server
software, and other problems. It can also detect directory traversal vulnerabilities.
4. DotDotPwn: This tool, as its name suggests, is specifically designed to test for directory
traversal vulnerabilities. It operates by sending specially crafted requests to the server
and analyzing the responses.
5. Metasploit: This is a penetration testing framework that contains modules for testing a
wide range of vulnerabilities, including directory traversal.
6. DirBuster: A tool from OWASP that aims to find hidden directories and files from
servers. It can also help in finding directory traversal endpoints.
The use of these tools underscores the importance of regular security testing and vulnerability
scanning in web applications. However, it is worth noting that these tools can also be misused
by threat actors, which reinforces the need for strong security measures and practices.
Preventing Directory Traversal Attacks
There are several strategies an organization can use to control and validate user input.
1. Input validation: This is the first line of defense against directory traversal attacks.
Ensure all user inputs are validated and sanitized before they are processed. Reject any
suspicious input containing special characters like `../` or `..\` used in directory traversal.
2. Use of allow lists: Instead of blocking known bad inputs (a blocklist), it’s more effective
allow known, good inputs (an allow list). For instance, if your application needs to access
specific files, list those files and only allow access to them.
3. Avoid using user input for file operations: If possible, avoid using user input to
access files. If you must, ensure the input is strongly validated and does not contain
directory traversal sequences.
4. Use of built-in functions to normalize paths: Many programming languages offer
functions that can normalize paths and remove any directory traversal sequences. For
instance, in PHP, you can use the `realpath()` function, and with JavaScript, the
`getCanonicalPath()` method can be used.
5. Least privilege principle: Ensure applications run with the least privileges necessary.
This can limit a potential directory traversal attack as the attacker can only gain access
to limited resources.
6. Regular security testing: Test applications regularly for security vulnerabilities. Tools
like Burp Suite, OWASP ZAP, Nikto, DotDotPwn, Metasploit, and DirBuster can help
identify potential directory traversal vulnerabilities.
The key to preventing directory traversal attacks lies in strong input validation, prudent coding
practices, and regular security testing.
How to Mitigate Directory Traversal Attacks
Mitigating the effects of a directory traversal attack involves a series of immediate and strategic
actions.
1. Incident response: As soon as a breach is detected, follow an established incident
response (IR) plan. This usually includes isolating the affected system to prevent further
compromise, conducting a thorough investigation to understand the extent of the breach,
and notifying affected parties and regulatory bodies if necessary.
2. Patch and update systems: Ensure that systems and applications are using the latest,
patched versions. Developers and vendors often release updates that fix security
vulnerabilities, including directory traversal. Regular patching can help mitigate the
damage from known vulnerabilities.
3. Deploy a Web Application Firewall (WAF): A WAF can provide an extra layer of
security by detecting and preventing attacks, including directory traversal attacks. It
works by examining HTTP traffic and identifying patterns or sequences that match
known attack vectors.
4. Regular audits and vulnerability assessments: Regularly conducting security audits
and vulnerability assessments can help you identify potential weaknesses in your
systems and applications.
5. Educate and train your team: The development and IT team should be familiar with the
concept of directory traversal attacks and other common web application vulnerabilities.
They should be trained in secure coding practices and kept up-to-date on the latest
threats and mitigation strategies.
6. Backup and recovery plan: Putting a robust backup and recovery plan in place can
help an organization recover quickly in the event of a serious attack. Regularly back up
all important data and ensure that systems can be restored after an incident occurs.
Difference between URI and URL
URI: Universal Resource Identifier
URL: Universal Resource Locator
Scheme indicates protocol such as ftp://, http://, https://, mongodb://
Host is the server’s identity.
Both URIs and URLs are pointers to things like web pages, images, documents, or other online
content. However, they have distinctive characteristics and functions that set them apart from
one another.
What is URL (Uniform Resource Locator)?
URL (Uniform Resource Locator) is often defined as a string of characters that is directed at an
address. It provides a way to retrieve the presentation of the physical location by describing its
network location or primary access mechanism.
Syntax of URL
Every HTTP URL adheres to its generic URI’s syntax. As a result, the syntax of the URL and the
URI are comparable. It is provided below:

Scheme: A scheme is the initial part of a URL; it is a protocol that a browser must
employ in order to seek a resource. HTTP and HTTPS are the protocols that are most
often used for websites.

Authority: The domain name and port, two sub-components of the authority, are
separated by a colon. The resource’s registered name, such as javatpoint.com, can be
used as the domain name, and the port on a web server serves as the technical entry
point to the resource. For HTTP, port 80 is used, and for HTTPS, port 443.

Path: The path on the web server shows the full route to the resource. A possible format
is /software/htp/index.html.

Query String: The string containing the name and value pair is known as the query
string. When it appears in a URL, the information is provided by following the path
component. “?key1=value1&key2=value2” is one example.

Fragment: It is an optional element that comes before the hash(#) symbol. It is made up
of a fragment identification that points the way to a backup resource.

For Ex: https://www.geeksforgeeks.org/difference-between-url-and-uri/
What is URI (Uniform Resource Identifier)?
Similar to URL, URI (Uniform Resource Identifier) is also a string of characters that identifies a
resource on the web either by using location, name or both. It allows uniform identification of the
resources. A URI is additionally grouped as a locator, a name or both which suggests it can
describe a URL, URN or both. The term identifier within the URI refers to the prominence of the
resources, despite the technique used.
The former category in URI is URL, during which a protocol is employed to specify the
accessing method of the resource and resource name is additionally laid out in the URL. A URL
may be a non-persistent sort of the URI. A URN is required to exist globally unique and features
a global scope. A string identifier that points to an online resource is called a URI, or uniform
resource identifier. Any resource on the internet can be identified by this string of characters by
either its name, its location, or both. Scheme, authority, path, query, and fragment are all
contained in a URI. The most widely used URI systems include ftp, Idap, telnet, HTTPs, HTTP
(Hypertext Transfer Protocol), etc.
Syntax of URI

Scheme: A scheme is the initial part of a Uniform Resource Locator (URI). It consists of
a string of characters, which can be any combination of a letter, number, plus sign, or
hyphen (_), and is followed by a colon (:). The most widely used protocols are irc, file,
ftp, data, and http. It is necessary to register the schemes with IANA.

Authority: Two slashes (//) come before the optional authority component. There are
three smaller parts to it:
o
user details: It might have a colon (:) between the username and an optional
password.
o
host: It has an IP address or a registered name on it. The IP address has to be
put in square brackets [] around it.
o
Path: Optional

Port: A series of path segments divided by a slash(/) make up this path. It is always
supplied by the URI; however, the path may be null or empty.

Query: It is an optional element that comes before the question mark (?). It has a nonhierarchical query string with data in it.

Fragment: It is an optional element that comes before the hash(#) symbol. It is made up
of a fragment identification that points the way to a backup
resource.
Difference Between URL and URI
URL
URI
URL is used to describe the identity of an item.
URI provides a technique for defining the
identity of an item.
URL links a web page, a component of a web
page or a program on a web page with the
help of accessing methods like protocols.
URI is used to distinguish one resource
from other regardless of the method used.
URL provides the details about what type of
protocol is to be used.
URI doesn’t contains the protocol
specification.
URL is a type of URI.
URI is the superset of URL.
It comprises protocol, domain, path, hash, and
so on.
It comprises scheme, authority, path, query
and many more.
URL
URI
Ex-https://www.geeksforgeeks.org/
Ex- urn:isbn:0-294-56559-3
What is a URN?
A Uniform Resource Name (URN) is a kind of Uniform Resource Identifier (URI) this is used to
uniquely perceive resources at the net in a chronic and region-unbiased way. Unlike Uniform
Resource Locators (URLs), which specify the location of a useful resource and how to get right
of entry to it, URNs are meant to function continual, globally specific identifiers for sources
irrespective of their contemporary region.
The primary reason of URNs is to provide a strong and lengthy-lasting identifier for resources,
even supposing their place or access strategies trade over time. URNs are normally used for
naming sources which include documents, articles, books, and other types of virtual content.
Frequently Asked Questions on URL and URI – FAQs
Can a URL contain space?
Spaces are not allowed in URLs. A space is typically replaced with a plus (+) symbol or %20 in
URL encoding.
What is the purpose of the query string in a URL?
URL parameters are components that are added to your URLs to assist with content
organization and filtering. They are sometimes referred to as query strings or URL query
parameters.
What is the purpose of a fragment identifier in a URI?
The final, optional portion of a document’s URL is the fragment identifier that a hash mark #
introduces. Usually, it is employed to designate a section of the document.
HTTP
What is HTTP?
The Hypertext Transfer Protocol (HTTP) is designed to enable communication between clients
and servers.
HTTP works as a request-response protocol between a client and server.
Example: A client (browser) sends an HTTP request to the server; then the server returns a
response to the client. The response contains status information about the request and may
also contain the requested content.
HTTP Methods



GET
POST
PUT






HEAD
DELETE
PATCH
OPTIONS
CONNECT
TRACE
The two most common HTTP methods are: GET and POST.
The GET Method
GET is used to request data from a specified resource.
Note that the query string (name/value pairs) is sent in the URL of a GET request:
/test/demo_form.php?name1=value1&name2=value2
Some notes on GET requests:

GET requests can be cached

GET requests remain in the browser history

GET requests can be bookmarked

GET requests should never be used when dealing with sensitive data

GET requests have length restrictions

GET requests are only used to request data (not modify)
The POST Method
POST is used to send data to a server to create/update a resource.
The data sent to the server with POST is stored in the request body of the HTTP request:
POST /test/demo_form.php HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2
Some notes on POST requests:

POST requests are never cached

POST requests do not remain in the browser history

POST requests cannot be bookmarked

POST requests have no restrictions on data length
Compare GET vs. POST
The following table compares the two HTTP methods: GET and POST.
GET
POST
BACK
button/Reload
Harmless
Data will be re-submitted (the browser
should alert the user that the data is
about to be re-submitted)
Bookmarked
Can be bookmarked
Cannot be bookmarked
Cached
Can be cached
Not cached
Encoding type
application/x-www-form-urlencoded
application/x-www-form-urlencoded or
multipart/form-data. Use multipart
encoding for binary data
History
Parameters remain in browser
history
Parameters are not saved in browser
history
Restrictions
on data length
Yes, when sending data, the GET
method adds the data to the URL;
and the length of a URL is limited
(maximum URL length is 2048
characters)
No restrictions
Restrictions
on data type
Only ASCII characters allowed
No restrictions. Binary data is also
allowed
Security
GET is less secure compared to
POST because data sent is part of
the URL
POST is a little safer than GET
because the parameters are not stored
in browser history or in web server
logs
Never use GET when sending
passwords or other sensitive
information!
Visibility
Data is visible to everyone in the
URL
Data is not displayed in the URL
The PUT Method
PUT is used to send data to a server to create/update a resource.
The difference between POST and PUT is that PUT requests are idempotent. That is, calling the
same PUT request multiple times will always produce the same result. In contrast, calling a
POST request repeatedly has side effects of creating the same resource multiple times.
The HEAD Method
HEAD is almost identical to GET, but without the response body.
In other words, if GET /users returns a list of users, then HEAD /users will make the same
request but will not return the list of users.
A HEAD request is useful for checking what a GET request will return before actually making a
GET request - a HEAD request can read the Content-Length header to check the size of the file,
without actually downloading the file.
The DELETE Method
The DELETE method deletes the specified resource.
The PATCH Method
The PATCH method is used to apply partial modifications to a resource.
The OPTIONS Method
The OPTIONS method describes the communication options for the target resource.
The CONNECT Method
The CONNECT method is used to start two-way communications (a tunnel) with the requested
resource.
The TRACE Method
The TRACE method is used to perform a message loop-back test that tests the path for the
target resource (useful for debugging purposes).
Common HTTP Responses
HTTP response status codes
HTTP response status codes indicate whether a specific HTTP request has been successfully
completed. Responses are grouped in five classes:
1. Informational responses (100 – 199)
2. Successful responses (200 – 299)
3. Redirection messages (300 – 399)
4. Client error responses (400 – 499)
5. Server error responses (500 – 599)
The status codes listed below are defined by RFC 9110.
Note: If you receive a response that is not listed here, it is a non-standard response, possibly
custom to the server's software.
Informational responses
100 Continue
This interim response indicates that the client should continue the request or ignore the
response if the request is already finished.
101 Switching Protocols
This code is sent in response to an Upgrade request header from the client and indicates the
protocol the server is switching to.
102 Processing Deprecated
This code was used in WebDAV contexts to indicate that a request has been received by the
server, but no status was available at the time of the response.
103 Early Hints
This status code is primarily intended to be used with the Link header, letting the user agent
start preloading resources while the server prepares a response or preconnect to an origin from
which the page will need resources.
Successful responses
200 OK
The request succeeded. The result and meaning of "success" depends on the HTTP method:

GET: The resource has been fetched and transmitted in the message body.

HEAD: Representation headers are included in the response without any message body.

PUT or POST: The resource describing the result of the action is transmitted in the
message body.

TRACE: The message body contains the request as received by the server.
201 Created
The request succeeded, and a new resource was created as a result. This is typically the
response sent after POST requests, or some PUT requests.
202 Accepted
The request has been received but not yet acted upon. It is noncommittal, since there is no way
in HTTP to later send an asynchronous response indicating the outcome of the request. It is
intended for cases where another process or server handles the request, or for batch
processing.
203 Non-Authoritative Information
This response code means the returned metadata is not exactly the same as is available from
the origin server, but is collected from a local or a third-party copy. This is mostly used for
mirrors or backups of another resource. Except for that specific case, the 200 OK response is
preferred to this status.
204 No Content
There is no content to send for this request, but the headers are useful. The user agent may
update its cached headers for this resource with the new ones.
205 Reset Content
Tells the user agent to reset the document which sent this request.
206 Partial Content
This response code is used in response to a range request when the client has requested a part
or parts of a resource.
207 Multi-Status (WebDAV)
Conveys information about multiple resources, for situations where multiple status codes might
be appropriate.
208 Already Reported (WebDAV)
Used inside a <dav:propstat> response element to avoid repeatedly enumerating the internal
members of multiple bindings to the same collection.
226 IM Used (HTTP Delta encoding)
The server has fulfilled a GET request for the resource, and the response is a representation of
the result of one or more instance-manipulations applied to the current instance.
Redirection messages
300 Multiple Choices
In agent-driven content negotiation, the request has more than one possible response and the
user agent or user should choose one of them. There is no standardized way for clients to
automatically choose one of the responses, so this is rarely used.
301 Moved Permanently
The URL of the requested resource has been changed permanently. The new URL is given in
the response.
302 Found
This response code means that the URI of requested resource has been changed temporarily.
Further changes in the URI might be made in the future, so the same URI should be used by the
client in future requests.
303 See Other
The server sent this response to direct the client to get the requested resource at another URI
with a GET request.
304 Not Modified
This is used for caching purposes. It tells the client that the response has not been modified, so
the client can continue to use the same cached version of the response.
305 Use Proxy Deprecated
Defined in a previous version of the HTTP specification to indicate that a requested response
must be accessed by a proxy. It has been deprecated due to security concerns regarding inband configuration of a proxy.
306 unused
This response code is no longer used; but is reserved. It was used in a previous version of the
HTTP/1.1 specification.
307 Temporary Redirect
The server sends this response to direct the client to get the requested resource at another URI
with the same method that was used in the prior request. This has the same semantics as
the 302 Found response code, with the exception that the user agent must not change the
HTTP method used: if a POST was used in the first request, a POST must be used in the
redirected request.
308 Permanent Redirect
This means that the resource is now permanently located at another URI, specified by
the Location response header. This has the same semantics as the 301 Moved
Permanently HTTP response code, with the exception that the user agent must not change the
HTTP method used: if a POST was used in the first request, a POST must be used in the
second request.
Client error responses
400 Bad Request
The server cannot or will not process the request due to something that is perceived to be a
client error (e.g., malformed request syntax, invalid request message framing, or deceptive
request routing).
401 Unauthorized
Although the HTTP standard specifies "unauthorized", semantically this response means
"unauthenticated". That is, the client must authenticate itself to get the requested response.
402 Payment Required
The initial purpose of this code was for digital payment systems, however this status code is
rarely used and no standard convention exists.
403 Forbidden
The client does not have access rights to the content; that is, it is unauthorized, so the server is
refusing to give the requested resource. Unlike 401 Unauthorized, the client's identity is known
to the server.
404 Not Found
The server cannot find the requested resource. In the browser, this means the URL is not
recognized. In an API, this can also mean that the endpoint is valid but the resource itself does
not exist. Servers may also send this response instead of 403 Forbidden to hide the existence
of a resource from an unauthorized client. This response code is probably the most well known
due to its frequent occurrence on the web.
405 Method Not Allowed
The request method is known by the server but is not supported by the target resource. For
example, an API may not allow DELETE on a resource, or the TRACE method entirely.
406 Not Acceptable
This response is sent when the web server, after performing server-driven content negotiation,
doesn't find any content that conforms to the criteria given by the user agent.
407 Proxy Authentication Required
This is similar to 401 Unauthorized but authentication is needed to be done by a proxy.
408 Request Timeout
This response is sent on an idle connection by some servers, even without any previous request
by the client. It means that the server would like to shut down this unused connection. This
response is used much more since some browsers use HTTP pre-connection mechanisms to
speed up browsing. Some servers may shut down a connection without sending this message.
409 Conflict
This response is sent when a request conflicts with the current state of the server.
In WebDAV remote web authoring, 409 responses are errors sent to the client so that a user
might be able to resolve a conflict and resubmit the request.
410 Gone
This response is sent when the requested content has been permanently deleted from server,
with no forwarding address. Clients are expected to remove their caches and links to the
resource. The HTTP specification intends this status code to be used for "limited-time,
promotional services". APIs should not feel compelled to indicate resources that have been
deleted with this status code.
411 Length Required
Server rejected the request because the Content-Length header field is not defined and the
server requires it.
412 Precondition Failed
In conditional requests, the client has indicated preconditions in its headers which the server
does not meet.
413 Content Too Large
The request body is larger than limits defined by server. The server might close the connection
or return an Retry-After header field.
414 URI Too Long
The URI requested by the client is longer than the server is willing to interpret.
415 Unsupported Media Type
The media format of the requested data is not supported by the server, so the server is rejecting
the request.
416 Range Not Satisfiable
The ranges specified by the Range header field in the request cannot be fulfilled. It's possible
that the range is outside the size of the target resource's data.
417 Expectation Failed
This response code means the expectation indicated by the Expect request header field cannot
be met by the server.
418 I'm a teapot
The server refuses the attempt to brew coffee with a teapot.
421 Misdirected Request
The request was directed at a server that is not able to produce a response. This can be sent by
a server that is not configured to produce responses for the combination of scheme and
authority that are included in the request URI.
422 Unprocessable Content (WebDAV)
The request was well-formed but was unable to be followed due to semantic errors.
423 Locked (WebDAV)
The resource that is being accessed is locked.
424 Failed Dependency (WebDAV)
The request failed due to failure of a previous request.
425 Too Early Experimental
Indicates that the server is unwilling to risk processing a request that might be replayed.
426 Upgrade Required
The server refuses to perform the request using the current protocol but might be willing to do
so after the client upgrades to a different protocol. The server sends an Upgrade header in a
426 response to indicate the required protocol(s).
428 Precondition Required
The origin server requires the request to be conditional. This response is intended to prevent
the 'lost update' problem, where a client GETs a resource's state, modifies it and PUTs it back
to the server, when meanwhile a third party has modified the state on the server, leading to a
conflict.
429 Too Many Requests
The user has sent too many requests in a given amount of time (rate limiting).
431 Request Header Fields Too Large
The server is unwilling to process the request because its header fields are too large. The
request may be resubmitted after reducing the size of the request header fields.
451 Unavailable For Legal Reasons
The user agent requested a resource that cannot legally be provided, such as a web page
censored by a government.
Server error responses
500 Internal Server Error
The server has encountered a situation it does not know how to handle. This error is generic,
indicating that the server cannot find a more appropriate 5XX status code to respond with.
501 Not Implemented
The request method is not supported by the server and cannot be handled. The only methods
that servers are required to support (and therefore that must not return this code)
are GET and HEAD.
502 Bad Gateway
This error response means that the server, while working as a gateway to get a response
needed to handle the request, got an invalid response.
503 Service Unavailable
The server is not ready to handle the request. Common causes are a server that is down for
maintenance or that is overloaded. Note that together with this response, a user-friendly page
explaining the problem should be sent. This response should be used for temporary conditions
and the Retry-After HTTP header should, if possible, contain the estimated time before the
recovery of the service. The webmaster must also take care about the caching-related headers
that are sent along with this response, as these temporary condition responses should usually
not be cached.
504 Gateway Timeout
This error response is given when the server is acting as a gateway and cannot get a response
in time.
505 HTTP Version Not Supported
The HTTP version used in the request is not supported by the server.
506 Variant Also Negotiates
The server has an internal configuration error: during content negotiation, the chosen variant is
configured to engage in content negotiation itself, which results in circular references when
creating responses.
507 Insufficient Storage (WebDAV)
The method could not be performed on the resource because the server is unable to store the
representation needed to successfully complete the request.
508 Loop Detected (WebDAV)
The server detected an infinite loop while processing the request.
510 Not Extended
The client request declares an HTTP Extension (RFC 2774) that should be used to process the
request, but the extension is not supported.
511 Network Authentication Required
Indicates that the client needs to authenticate to gain network access.
WASM
WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual
machine. Wasm is designed as a portable compilation target for programming languages,
enabling deployment on the web for client and server applications.
XSS (Cross-site scripting)
Cross-site scripting (XSS) is a type of security vulnerability that can be found in some web
applications. XSS attacks enable attackers to inject client-side scripts into web pages viewed by
other users.
TLS
What is Transport Layer Security (TLS)?
Transport Layer Security, or TLS, is a widely adopted security protocol designed to facilitate
privacy and data security for communications over the Internet. A primary use case of TLS is
encrypting the communication between web applications and servers, such as web browsers
loading a website. TLS can also be used to encrypt other communications such as email,
messaging, and voice over IP (VoIP).
TLS was proposed by the Internet Engineering Task Force (IETF), an international standards
organization, and the first version of the protocol was published in 1999. The most recent
version is TLS 1.3, which was published in 2018.
What is the difference between TLS and SSL?
TLS evolved from a previous encryption protocol called Secure Sockets Layer (SSL), which was
developed by Netscape. TLS version 1.0 actually began development as SSL version 3.1, but
the name of the protocol was changed before publication in order to indicate that it was no
longer associated with Netscape. Because of this history, the terms TLS and SSL are
sometimes used interchangeably.
What is the difference between TLS and HTTPS?
HTTPS is an implementation of TLS encryption on top of the HTTP protocol, which is used by
all websites as well as some other web services. Any website that uses HTTPS is therefore
employing TLS encryption.
Why should businesses and web applications use the TLS protocol?
TLS encryption can help protect web applications from data breaches and other attacks. Today,
TLS-protected HTTPS is a standard practice for websites. The Google Chrome browser
gradually cracked down on non-HTTPS sites, and other browsers have followed suit. Everyday
Internet users are more wary of websites that do not feature the HTTPS padlock icon.
What does TLS do?
There are three main components that the TLS protocol accomplishes: Encryption,
Authentication, and Integrity.

Encryption: hides the data being transferred from third parties.

Authentication: ensures that the parties exchanging information are who they claim to
be.

Integrity: verifies that the data has not been forged or tampered with.
What is a TLS certificate?
For a website or application to use TLS, it must have a TLS certificate installed on its origin
server (the certificate is also known as an "SSL certificate" because of the naming confusion
described above). A TLS certificate is issued by a certificate authority to the person or business
that owns a domain. The certificate contains important information about who owns the domain,
along with the server's public key, both of which are important for validating the server's identity.
How does TLS work?
A TLS connection is initiated using a sequence known as the TLS handshake. When a user
navigates to a website that uses TLS, the TLS handshake begins between the user's device
(also known as the client device) and the web server.
During the TLS handshake, the user's device and the web server:

Specify which version of TLS (TLS 1.0, 1.2, 1.3, etc.) they will use

Decide on which cipher suites (see below) they will use

Authenticate the identity of the server using the server's TLS certificate

Generate session keys for encrypting messages between them after the handshake is
complete
The TLS handshake establishes a cipher suite for each communication session. The cipher
suite is a set of algorithms that specifies details such as which shared encryption keys,
or session keys, will be used for that particular session. TLS is able to set the matching session
keys over an unencrypted channel thanks to a technology known as public key cryptography.
The handshake also handles authentication, which usually consists of the server proving its
identity to the client. This is done using public keys. Public keys are encryption keys that use
one-way encryption, meaning that anyone with the public key can unscramble the data
encrypted with the server's private key to ensure its authenticity, but only the original sender can
encrypt data with the private key. The server's public key is part of its TLS certificate.
Once data is encrypted and authenticated, it is then signed with a message authentication code
(MAC). The recipient can then verify the MAC to ensure the integrity of the data. This is kind of
like the tamper-proof foil found on a bottle of aspirin; the consumer knows no one has tampered
with their medicine because the foil is intact when they purchase it.
How does TLS affect web application performance?
The latest versions of TLS hardly impact web application performance at all.
Because of the complex process involved in setting up a TLS connection, some load time and
computational power must be expended. The client and server must communicate back and
forth several times before any data is transmitted, and that eats up precious milliseconds of load
times for web applications, as well as some memory for both the client and the server.
However, there are technologies in place that help to mitigate potential latency created by the
TLS handshake. One is TLS False Start, which lets the server and client start transmitting data
before the TLS handshake is complete. Another technology to speed up TLS is TLS Session
Resumption, which allows clients and servers that have previously communicated to use an
abbreviated handshake.
These improvements have helped to make TLS a very fast protocol that should not noticeably
affect load times. As for the computational costs associated with TLS, they are mostly negligible
by today’s standards.
TLS 1.3, released in 2018, has made TLS even faster. TLS handshakes in TLS 1.3 only require
one round trip (or back-and-forth communication) instead of two, shortening the process by a
few milliseconds. When the user has connected to a website before, the TLS handshake has
zero round trips, speeding it up still further.
ARP Poisoning/ Spoofing
ARP Poisoning (also known as ARP Spoofing) is a type of cyber attack carried out over a Local
Area Network (LAN) that involves sending malicious ARP packets to a default gateway on a
LAN in order to change the pairings in its IP to MAC address table. ARP Protocol translates IP
addresses into MAC addresses. Because the ARP protocol was designed purely for efficiency
and not for security, ARP Poisoning attacks are extremely easy to carry out as long as the
attacker has control of a machine within the target LAN or is directly connected to it.
The attack itself consists of an attacker sending a false ARP reply message to the default
network gateway, informing it that his or her MAC address should be associated with his or her
target's IP address (and vice-versa, so his or her target's MAC is now associated with the
attacker's IP address). Once the default gateway has received this message and broadcasts its
changes to all other devices on the network, all of the target's traffic to any other device on the
network travels through the attacker's computer, allowing the attacker to inspect or modify it
before forwarding it to its real destination. Because ARP Poisoning attacks occur on such a low
level, users targeted by ARP Poisoning rarely realize that their traffic is being inspected or
modified. Besides Man-in-the-Middle Attacks, ARP Poisoning can be used to cause a denial-ofservice condition over a LAN by simply intercepting or dropping and not forwarding the target's
packets.
Persistent (Sticky) MAC Learning
Persistent (Sticky) MAC is a Layer 2 port security feature that prevents unauthorized devices
from connecting to your network. When this feature is enabled, the switch will observe the
incoming source MAC addresses on a configured port and dynamically learn/save this address
to memory. You can set the maximum number of MAC addresses learned. After the maximum
limit is reached, any device attempting to connect to the port will have their frames dropped and
logged.
Content Injection
Content injection is a generic name for a class of attacks thar present user-content (3P) as
service content (1P).


Implementation vulnerability
Client-side processing and harm
Content Injection is an attack that injects arbitrary characters into a web page. When an
application does not properly handle user-supplied data, an attacker can supply content to a
web application, typically via a parameter value which is then reflected in the page. This attack
is typically used as, or in conjunction with, social engineering by transmitting a URL that
completely modifies the target page with, for example, a fake authentication test pattern in order
to steal the user's identifiers. In some cases, this attack can also lead directly or indirectly to a
Cross-Site Scripting or a client-side JSON injection.

Solution

To prevent Content Injection vulnerabilities, it is important to never use untrusted or
unfiltered data within the code of a HTML page.
Untrusted data can originate not only from the client but potentially a third party or
previously uploaded file etc.
Filtering of untrusted data typically involves converting special characters to their HTML
entity encoded counterparts (however, other methods do exist, see references). These
special characters include:
* `&` * `<` * `>` * `'` * `'` * `/`
An example of HTML entity encoding is converting `<` to `&lt;`.
Although it is possible to filter untrusted input, there are five locations within an HTML
page where untrusted input (even if it has been filtered) should never be placed:
1. Directly in a script. 2. Inside an HTML comment. 3. In an attribute name. 4. In a tag
name. 5. Directly in CSS.
Each of these locations has their own form of escaping and filtering.
Content Injection Sources
Server relayed content


Attacker uploads data (malicious user content) to a website
Server sends data (malicious user content) to victim as site data
URLs


Server copies data from URL to victim’s page
Attacker convinces victim to click on link
Preventing Content Injection
1. Don’t use user-provided data.. ever
 Create/ store server-side and give client DB key
2. Protect data stored by client-side with a server-only secret used to validate
 AES-GCM (keyserver-only, “Bob”)
 “Bob”+HMAC(keyserver-only, “Bob”)
3. Validate *everything* about client supplied data every time you touch it
 re.search(“^[a-zA-Z]{2,}]$”, data)
Cross-Site Scripting (XSS)
XSS is a class of attacks which extends Content Injection to execute JavaScript in the victim’s
browser.


Content injection attack with JS injected
Often use “polyglots” to test websites
Preventing XSS



Same as before (don’t/protect/validate)
Avoid dangerous patterns
o Dom_ele.innerHTML = untrusted_data
o Eval(validate(untrusted_data)
Escape user-provided data
o “<”  “&lt;” (still renders as “<”)
What is cross-site scripting (XSS)?
Cross-site scripting (also known as XSS) is a web security vulnerability that allows an attacker
to compromise the interactions that users have with a vulnerable application. It allows an
attacker to circumvent the same origin policy, which is designed to segregate different websites
from each other. Cross-site scripting vulnerabilities normally allow an attacker to masquerade as
a victim user, to carry out any actions that the user is able to perform, and to access any of the
user's data. If the victim user has privileged access within the application, then the attacker
might be able to gain full control over all of the application's functionality and data.
How does XSS work?
Cross-site scripting works by manipulating a vulnerable web site so that it returns malicious
JavaScript to users. When the malicious code executes inside a victim's browser, the attacker
can fully compromise their interaction with the application.
Labs
If you're already familiar with the basic concepts behind XSS vulnerabilities and just want to
practice exploiting them on some realistic, deliberately vulnerable targets, you can access all of
the labs in this topic from the link below.

View all XSS labs
XSS proof of concept
You can confirm most kinds of XSS vulnerability by injecting a payload that causes your own
browser to execute some arbitrary JavaScript. It's long been common practice to use
the alert() function for this purpose because it's short, harmless, and pretty hard to miss when
it's successfully called. In fact, you solve the majority of our XSS labs by invoking alert() in a
simulated victim's browser.
Unfortunately, there's a slight hitch if you use Chrome. From version 92 onward (July 20th,
2021), cross-origin iframes are prevented from calling alert(). As these are used to construct
some of the more advanced XSS attacks, you'll sometimes need to use an alternative PoC
payload. In this scenario, we recommend the print() function. If you're interested in learning
more about this change and why we like print(), check out our blog post on the subject.
As the simulated victim in our labs uses Chrome, we've amended the affected labs so that they
can also be solved using print(). We've indicated this in the instructions wherever relevant.
What are the types of XSS attacks?
There are three main types of XSS attacks. These are:

Reflected XSS, where the malicious script comes from the current HTTP request.

Stored XSS, where the malicious script comes from the website's database.

DOM-based XSS, where the vulnerability exists in client-side code rather than serverside code.
Reflected cross-site scripting
Reflected XSS is the simplest variety of cross-site scripting. It arises when an application
receives data in an HTTP request and includes that data within the immediate response in an
unsafe way.
Here is a simple example of a reflected XSS vulnerability:
https://insecure-website.com/status?message=All+is+well.
<p>Status: All is well.</p>
The application doesn't perform any other processing of the data, so an attacker can easily
construct an attack like this:
https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>
<p>Status: <script>/* Bad stuff here... */</script></p>
If the user visits the URL constructed by the attacker, then the attacker's script executes in the
user's browser, in the context of that user's session with the application. At that point, the script
can carry out any action, and retrieve any data, to which the user has access.
Read more

Reflected cross-site scripting

Cross-site scripting cheat sheet
Stored cross-site scripting
Stored XSS (also known as persistent or second-order XSS) arises when an application
receives data from an untrusted source and includes that data within its later HTTP responses
in an unsafe way.
The data in question might be submitted to the application via HTTP requests; for example,
comments on a blog post, user nicknames in a chat room, or contact details on a customer
order. In other cases, the data might arrive from other untrusted sources; for example, a
webmail application displaying messages received over SMTP, a marketing application
displaying social media posts, or a network monitoring application displaying packet data from
network traffic.
Here is a simple example of a stored XSS vulnerability. A message board application lets users
submit messages, which are displayed to other users:
<p>Hello, this is my message!</p>
The application doesn't perform any other processing of the data, so an attacker can easily
send a message that attacks other users:
<p><script>/* Bad stuff here... */</script></p>
DOM-based cross-site scripting
DOM-based XSS (also known as DOM XSS) arises when an application contains some clientside JavaScript that processes data from an untrusted source in an unsafe way, usually by
writing the data back to the DOM.
In the following example, an application uses some JavaScript to read the value from an input
field and write that value to an element within the HTML:
var search = document.getElementById('search').value;
var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;
If the attacker can control the value of the input field, they can easily construct a malicious value
that causes their own script to execute:
You searched for: <img src=1 onerror='/* Bad stuff here... */'>
In a typical case, the input field would be populated from part of the HTTP request, such as a
URL query string parameter, allowing the attacker to deliver an attack using a malicious URL, in
the same manner as reflected XSS.
What can XSS be used for?
An attacker who exploits a cross-site scripting vulnerability is typically able to:

Impersonate or masquerade as the victim user.

Carry out any action that the user is able to perform.

Read any data that the user is able to access.

Capture the user's login credentials.

Perform virtual defacement of the web site.

Inject trojan functionality into the web site.
Impact of XSS vulnerabilities
The actual impact of an XSS attack generally depends on the nature of the application, its
functionality and data, and the status of the compromised user. For example:

In a brochureware application, where all users are anonymous and all information is
public, the impact will often be minimal.

In an application holding sensitive data, such as banking transactions, emails, or
healthcare records, the impact will usually be serious.

If the compromised user has elevated privileges within the application, then the impact
will generally be critical, allowing the attacker to take full control of the vulnerable
application and compromise all users and their data.
How to prevent XSS attacks
Preventing cross-site scripting is trivial in some cases but can be much harder depending on the
complexity of the application and the ways it handles user-controllable data.
In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the
following measures:

Filter input on arrival. At the point where user input is received, filter as strictly as
possible based on what is expected or valid input.

Encode data on output. At the point where user-controllable data is output in HTTP
responses, encode the output to prevent it from being interpreted as active content.
Depending on the output context, this might require applying combinations of HTML,
URL, JavaScript, and CSS encoding.

Use appropriate response headers. To prevent XSS in HTTP responses that aren't
intended to contain any HTML or JavaScript, you can use the Content-Type and XContent-Type-Options headers to ensure that browsers interpret the responses in the
way you intend.

Content Security Policy. As a last line of defense, you can use Content Security Policy
(CSP) to reduce the severity of any XSS vulnerabilities that still occur.
HTTP Cookies
Cookies are small data chunks that the client stores and returns the server with requests.
Some uses:



Personalization info
Client-specific state
Session authentication
Authentication Cookies
Authentication cookies track whether a user is logged in and under what name. They also
streamline login information, so users don't have to remember site passwords.
Cross-Site Request Forgery (CSRF)
CSRF is a class of attacks that extends XSS to maliciously use client-side credentials.

XSS which makes requests from the client’s browser to an authenticated API
CSRF example:
When XSS is rendered, the client makes an attacker’s chosen POST request w/ existing
credentials
Preventing CSRF



Use SameSite cookie attribute
o Cookie will only be sent on requests that originate from the original sender
Secret HTML tokens
o Website adds random tokens to its form-inputs and ensures that they are
returned
Referrer Validation
o The server checks the contents of the referrer header in order to validate
request’s origin
Same-Origin Policy
The Same-Origin Policy is a client-side mechanism to restrict how two pieces of content can
interact with each other.



“Origin” is defined by (scheme, host, port)
Unless is the same-origin, many restrictions on how content can interact
Cookies, requests, scripts, & iframes all have their own rules and mechanisms
o There are a million caveats
Content Security Policy (CSP)
CSP is a way for websites to whitelist content sources via HTTP protocol header.


HTTP header lists the allowed sources
o Content-Security-Policy: default-src ‘self’ *.example.com *.other.com
Browser blocks sources not in list
o Think of as “a firewall for HTML”
Cross-Origin Resource Sharing (CORS)
CORS is a mechanism that allows different origins to treat each other as the same origin.
OPTIONS /
Host: service.example.com
Origin: http://ww.example.com
Access-Control-Request-Method: PUT


Uses “preflight” requests to ensure allowed
Operates as a complement to CSP
Privacy
Privacy, at an extremely simplistic level, is the fundamental right to control what people know
about you.
Internet Privacy
Internet privacy is the right to control what data you share, when you share it, and who it is
shared with.
Network-Level Injection


ISPs caught inserting content into customers’ traffic to serve ads
ISPs caught inserting user-identifiers into customers’ traffic to allow others to track
Network-Level Monitoring



ISPs passively monitor customers’ traffic for tracking
User agrees to thousand-page ToS which hides usage
Companies treat as new revenue source
End-Point Confidentiality
Endpoint security or endpoint protection is an approach to the protection of computer
networks that are remotely bridged to client devices. The connection of endpoint devices such
as laptops, tablets, mobile phones, and other wireless devices to corporate networks creates
attack paths for security threats.[1] Endpoint security attempts to ensure that such devices
follow compliance to standards.
Endpoint security systems operate on a client-server model, with the security program
controlled by a centrally managed host server pinned[clarification needed] with a client program that is
installed on all the network drives.[citation needed][7] There is another model called software as a
service (SaaS), where the security programs and the host server are maintained remotely by
the merchant. In the payment card industry, the contribution from both the delivery models is
that the server program verifies and authenticates the user login credentials and performs a
device scan to check if it complies with designated corporate security standards prior to
permitting network access.
HTML Resource Fetching
An HTML page fetches different parts of the page from different servers.
Remote Content Fetching
A web page uses contents from other websites to integrate in its own.
Tracking Pixels
Tracking Pixels are images which encode cookie-like identifiers into the image URL.


Usually 1-5 pixels large
Usually transparent
e.g., <img height=”1” width=”1” src=”fb.com/img/id=784c39”/>
A tracking pixel is an HTML code snippet which is loaded when a user visits a website or opens
an email. It is useful for tracking user behavior and conversions. With a tracking pixel,
advertisers can acquire data for online marketing, web analysis or email marketing. With log file
analysis, long data evaluation or using appropriate analytical tools, this data can be used for
different purposes, for example retargeting.
3rd Party Web Cookies
Third-Party Cookies are mechanisms which allow non-obvious/undesired websites to track web
clients across various 1P websites.
Third-party cookies are cookies that are set by a website other than the one you are
currently on. For example, you can have a "Like" button on your website which will store
a cookie on a visitor's computer, that cookie can later be accessed by Facebook to
identify visitors and see which websites they visited. Such a cookie is considered to be a
third-party cookie.
Another example would be an advertising services like Google Ads also create third-party
cookies to monitor which websites were visited by each user. This is the main technology used
to show you products that you previously searched for on a completely different website.
Browser-Level Isolation
Profiles – Containers
Manually-switched browser instances
Auto-switched cookie stores
Use an Ad-Blocker



Contains a list of known domains and URL patterns
If a web request matches that list, it is blocked within the browser
Very, very few websites break
Chromium Manifest v3
With the deprecation of Manifest API v2, ad blockers will become significantly limited in all
Chromium-based browsers
Manifest V3 aims to be the first step in our platform vision to improve the privacy, security, and
performance of extensions. Along with the platform changes, we are working to give users more
understanding and control over what extensions are capable of. The changes will take several
years to complete.
Dynamic Privacy Extensions
Dynamically decides whether to allow cookies and dynamic content

Most are behavior-based and not rule-based
Email Tracking
Email tracking is when you monitor relevant activity and actions taken after an email has been
sent.
For instance, after sending an email, you may want to know whether or not the recipient opened
your email. With email tracking, you can see if the recipient opened your email and better
understand how they interacted with your email marketing campaign.
In addition to telling you whether a recipient opened your email, an email tracking tool can also
tell you the time and date at which the email was opened and, in some cases, even the location.
Link Tracking


Shady entities send custom link to users
Used to connect email + 1P cookies
o Service sets cookieX without knowing user
o Service sends custom URL to Alice
o When clicked service sees URL + cookies
Disable Email Images



Some services and clients allow you to block images
Sometimes they can but ignore setting
Some pretend to offer but only have partial support
Private Browsing Mode



Meant for short-term usage
Each instantiation is completely isolated
o No cookies shared
o No history
o No cache
Opening and closing profile clears the most identifiers
TLS Protocol


TLS = Transport Layer Security
Used to protect most of the common Internet protocols
o HTTP  HTTPS
o FTP  FTPS
o SMTP  SMTPS
o Some VPNs
o Many, many more
TLS Protocol Characteristics



Content agnostic
One or both endpoints can be authenticated
Well-studied and iteratively improved
SSL Protocol vs TLS Protocol
SSL Protocol – 3 versions (1, 2, 3). All versions are insecure.
TLS Protocol – 4 versions (1.0, 1.1, 1.2 and 1.3). 1.2 and 1.3 are current.
SSL, TLS, and HTTPS are often used interchangeably in the real-world. When in doubt, make
sure it’s TLS!
Why use TLS Protocol?


Provides generic, secure channel with little overhead and in-place infrastructure
o Low-latency, low bandwidth, etc.
o Most languages/libraries already support
Getting the details correct for a secure channel is very difficult so allow focus
o 1,000 people studying 500 protocols (BAD)
o 1,000 people studying 1 protocol (GOOD)
TLS content link: https://www.kiteworks.com/risk-compliance-glossary/transport-layer-securitytls/
Phase1: Parameter Negotiation


GOAL: Determine how endpoints will communicate
o Symmetric cipher
o Signature algorithm
o KEX method
Arbitrary additions
o Many are generic
o Some are specific to the internal data
Does HTTPS Upgrade via 3XX redirects ensure HTTPS is being used?
No. If there is Man in the middle attack, man in the middle may be connected through https but
actual user might remain connected through http.
The proxy can block https and only allow http from the browser. Then it can initiate its own https
connection to pass the requests to the server.
Most users will not notice.
HSTS is supposed to stop this but it is not widely used.
Why HTTPS/TLS is insecure
While your connection to a server may be encrypted and tamper-proof, anyone with adequate
resources can place a MITM machine between you and the public website's server.
So long as MITM machine has a valid certificate chain, it can then show your browser a fake
version of the website, or even modify the data being sent back and forth.
This issue is exacerbated by the fact that there are now free certificates available from
companies like Cloudflare and Let's Encrypt. So, it is very easy for MITM machines to get valid
certificate chains.
Potential Solution
All networked computers should record the history of received TLS certificates per public
website and send it to a public database for attestation. This would allow users to compare the
fingerprints of certificates by different geolocations and potentially uncover any MITM attacks.
Although this is not a complete solution, it would at least give users some indication of whether
or not they have been the victim of a MITM attack.
How does HTTP Strict Transport Security HSTS mitigate man-in-the-middle attacks?
The way this protection works is that when a user entering or selecting an HTTP (not HTTPS)
URL to the site, the client, such as a Web browser, will automatically upgrade to HTTPS without
making an HTTP request, thereby preventing any HTTP man-in-the-middle attack from
occurring.
HSTS
Hypertext Strict Transport Security (HSTS) is a mechanism that allows a server to instruct a
browser to only communicate over HTTPS to domain via HTTP header.

Implicitly upgrades all URLs on domain

Includes an expiration of such instruction
HSTS stands for HTTP Strict Transport Security and creates a policy that says the browser
shouldn’t open a page that does not have a HTTPS connection and should redirect users from
the HTTP version of the site to the HTTPS version of the site when possible. Implementing this
type of policy on all company-owned devices prevents users from visiting unsecured websites
since it means they won’t be able to open a page with a HTTP connection.
Enable secure cookies for all company users
All websites use cookies to identify and remember users during the course of their session.
Enabling secure cookies for all of your company’s users means that all of the cookies their
browsers use will have secure attributes and can only be sent over secure HTTPS connections,
not insecure HTTP connections.
SSL Stripping Attack
An SSL stripping attack is where an active network attacker prevents a server from upgrading
clients to HTTPS.



Client sees HTTP
Server sees HTTPS
MitM attacker passes messages between the two protocols
There are generally three ways hackers can gain the necessary access to execute SSL
stripping attacks:

Proxy servers: Hackers can manually set a user’s browser proxy to route all traffic to
their own external server. This means every web request users make will go to the
hacker, who can then take over and establish manipulative connections based on each
request.

ARP spoofing: Hackers connect to a user’s IP address through a spoofed address
resolution protocol (ARP) message. Once they connect in this way, they can receive any
data intended for the legitimate user’s IP address.

Network access: Hackers can create a fake public wifi network and once users connect
to that network, they can control all communications that occur on it. If hackers can gain
access to any secure network, they can also execute the attack in a similar way.
Does HSTS prevent SSL Stripping Attacks?
HSTS Preload
HSTS Preload is a list of domains to apply HSTS to which is compiled into the browser.
What is HSTS Preloading
HSTS Preloading is a mechanism whereby a list of hosts that wish to enforce the use of
SSL/TLS on their site is built into a browser. This list is compiled by Google and is utilized by
Chrome, Firefox and Safari. These sites do not depend on the issuing of the HSTS response
header to enforce the policy, instead the browser is already aware that the host requires the use
of SSL/TLS before any connection or communication even takes place. This removes the
opportunity an attacker has to intercept and tamper with redirects that take place over HTTP.
This isn't to say that the host needs to stop issuing the HSTS response header, this must be left
in place for those browsers that don't use preloaded HSTS lists.
Does HSTS Preload prevent SSL stripping attack?
Probably yes.
SSL Certificate Chain
In our example, the SSL certificate chain is represented by 6 certificates:
1. End-user Certificate - Issued to: example.awesome; Issued By: Awesome Authority
2. Intermediate Certificate 1 - Issued to: Awesome Authority; Issued By: Intermediate
Awesome CA Alpha
3. Intermediate Certificate 2 - Issued to: Intermediate Awesome CA Alpha; Issued By:
Intermediate Awesome CA Beta
4. Intermediate Certificate 3 - Issued to: Intermediate Awesome CA Beta; Issued By:
Intermediate Awesome CA Gamma
5. Intermediate Certificate 4 - Issued to: Intermediate Awesome CA Gamma; Issued By:
The King of Awesomeness
6. Root certificate - Issued by and to: The King of Awesomeness
Certificate Transparency


When issuing an SSL certificate, CA must notify 3rd parties of the details of the certificate
Will eventually be a repository of all currently-valid SSL certificates
TLS 1.3


Single round-trip required for full connection
o ~100ms latency
May require additional due to optimistic contents
QUIC
The QUIC protocol is a UDP-based alternative to TLS designed by Google for experimenting
with new ideas.



Similar to TLS but some major changes
Heavily contributed to features and structure HTTP/2 and TLS1.3
HTTP/3 uses QUIC instead TLS
Advantages/Disadvantages of VPN
Advantages of VPN
Bypassing Geo-Restrictions
Geo-restrictions are a method used to control content in that only people from a particular
region can access certain platforms or content. The platforms restrict users from accessing
them because they can see their geographical location using the IP address.
When users want to access such geographical restricted content, they need to deploy a VPN
that will hide their actual IP address and place them in a zone acceptable to the platform. Some
entertainment platforms are also geo-restricted, but you can have unlimited access to the
platform by use of the VPN
It Increases Your Online Privacy.
When you log into a website, that website can see your actual IP address. An IP address is a
big deal because it reveals your exact location, the country you are logging in from, your city,
your ISP, and even your zip code.
Anytime you surf the internet, you leave a footprint. The ISPS can track and sell this kind of data
to advertisers who, by using your footprint, can create a customer profile for you so accurately
that they target you with particular adverts.
Deploying a VPN when surfing the internet hides your IP address, which frees you from this kind
of danger.
It Protects You from Cyber Attacks.
Cybercrimes are getting stronger every day. They can eavesdrop on all your network
connections and most especially WI-FI. Cybercriminals can create spoof Wi-Fi connections that
trick users into connecting, and they mostly create fake Wi-Fi connections using public Wi-Fi.
When a user connects with them, they have the capability of stealing your confidential
information such as bank and credit card details. In preventing this, a user should use a VPN. A
VPN encrypts your connection, making it gibberish to the attackers and safeguarding all your
personal private information.
You Free Yourself from Online Censorship.
There are countries like China whose governments impose bans on certain online websites and
services. The great wall of china, for example, prohibits all users located in china from
accessing certain websites and applications.
Using a VPN gives the user a fake IP address away from china, meaning that all the china
prohibitions will not apply to you. And you will surf the internet without restrictions even when
still living in china. This also applies to any ISP-imposed restrictions.
Prevents Bandwidth Throttling
Bandwidth throttling limits the bandwidth. This mostly happens to users using the internet
regularly, and it’s done either once a week or once a month by the ISPs and could make you
purchase higher data plans and subscriptions.
By using a VPN, you bar the ISP from monitoring your activities online and the consumed
bandwidth. This means that even if you use more bandwidth, the ISP will not notice therefore
will not take any action.
Super Network Scalability
Network scalability is measured by the ease by any network to add or remove devices on its
network. Though many companies prefer a private network, it requires a huge budget to create
and set up, making it quite expensive. The private network assigns its private IPS to the devices
on its network.
To reduce such costs and increase network scalability, the VPN uses public networks and works
efficiently while connecting internationally.
Disadvantages of VPN
Slows Down the Internet Speed
A VPN goes through an encryption process to secure your data, and this takes time and could
potentially negate your online experience. Some VPNs are also way slower than others, and
therefore a user should choose a VPN that offers high speeds and does not compromise their
security.
Rerouting, data encryption, and the maintenance of a certain amount of bandwidth are the most
probable causes of slow internet speeds. It would help if you, therefore, considered using VPNs
with minimal connection loss and high speeds.
Some countries use VPN blockers to block people using VPN to access content and websites
that the government feels are inappropriate and this also significantly impacts the effectiveness
and speed of the VPN.
Stronger Anti-VPN Software’s
The market today has come up with more robust anti-VPN software. There are also those
countries that consider the use of Virtual Private Networks VPN illegal. Therefore, they have
come up with anti-VPN software that is meant to bar or block anyone trying to access
information, websites, and content not allowed.
Users must strive to use the VPN that stands a chance against these potent VPN blockers.
Using a paid VPN is the first step to resolving this issue.
Connection Dropping
One of the biggest fears a VPN user has is the dropping of their connection. This is because
once the connection is lost, the encrypted connection no longer works, your IP address is
exposed, and your anonymity is lost.
Some VPNs have a kill switch feature. This is a critical feature to VPNs because once the VPN
encrypted connection is lost, the kill switch instantly disconnects from the internet, keeping you
safe, secure, and your identity anonymous.
Configuration Difficulty
Not every VPN service is well configured, and an improperly configured VPN could easily make
your confidential information vulnerable. Improperly configured VPN leads to IP and DNS leaks.
It is not also easy to set up and configure a VPN connection manually because of the complex
physical components used in the connection. Reading a guide or a manual may feel like you are
trying to learn a foreign language due to the terminology.
It’s therefore advisable to offer a VPN service that has good user-friendly experiences if you are
not tech-savvy. A user-friendly provider will make your VPN experience painless, smooth, and
fun.