Hubbry Logo
ClobberingClobberingMain
Open search
Clobbering
Community hub
Clobbering
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Clobbering
Clobbering
Clobbering
View on Wikipedia
from Wikipedia
Clobbered Qing dynasty bowl, the added decoration presumably 19th-century

In computing, clobbering is the act of overwriting a resource such as a file, processor register or a region of memory, such that its content is lost. Generally, the term is used in the context of unintentional loss of information, but it can be used for intentional overwriting as well.[1] The Jargon File defines clobbering as

To overwrite, usually unintentionally: "I walked off the end of the array and clobbered the stack." Compare mung, scribble, trash, and smash the stack.[2]

The term originated in pottery, where clobbering is a traditional term for the deceptive and fraudulent later addition of decoration to an originally plain piece. This was especially done to Chinese porcelain, but also European wares.[3]

Examples

[edit]

File redirection

[edit]

In many shells, the > file redirection operator clobbers if the output path refers to an existing file. This can be prevented in bash and ksh via the command set -o noclobber and in csh and tcsh via set noclobber. Subsequently, attempting to clobber via redirection fails with an error message.[4] For example: 

$ echo "Hello, world" >file.txt
$ cat file.txt
Hello, world
$ echo "This will overwrite the first greeting." >file.txt
$ cat file.txt
This will overwrite the first greeting.
$ set -o noclobber
$ echo "Can we overwrite it again?" >file.txt
-bash: file.txt: cannot overwrite existing file
$ echo "But we can use the >| operator to ignore the noclobber." >|file.txt
$ cat file.txt # Successfully overwrote the contents of file.txt using the >| operator
But we can use the >| operator to ignore the noclobber.
$ set +o noclobber # Changes setting back

File mv and cp

[edit]

The default behavior of the mv and cp commands is to clobber an existing destination file. This behavior may be overridden via the -i option which results in prompting the user to confirm clobbering a file. Alternatively, the -n option selects to skip operations that would clobber.

Makefiles

[edit]

A commonly used make target, named clobber, performs a complete cleanup of files and directories produced via previous invocations of the command for a particular makefile.[5] It is a more thorough cleanup operation than clean and is commonly used to uninstall software. Some make-related commands invoke make clobber during their execution. They check the CLOBBER environment variable. If it is set to OFF then clobbering is not done.[6]

Assembly

[edit]

In assembler programming (including GCC inline assembly[7]) a clobbered register denotes a register whose value may be overwritten in the course of executing an instruction.

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Clobbering

View on Grokipedia
from Grokipedia
Clobbering is an informal English noun referring to a severe physical beating or thrashing, or more broadly to a decisive and overwhelming defeat in a , conflict, or endeavor. The term derives from the verb clobber, which means to strike someone or something hard and repeatedly, often with punitive intent. The word clobber as a emerged in around 1941, primarily within contexts during , where it likely originated as onomatopoeic slang mimicking the sound of distant bomb detonations or related to aerial bombing actions. Its earliest documented use in this sense dates to the , evolving from wartime to wider colloquial usage by the mid-20th century. Over time, clobbering has extended metaphorically to describe non-physical routs, such as a sports team dominating opponents or policies harshly impacting an economy. Beyond slang, clobbering has specialized applications in technical domains. In computing, it denotes the overwriting of data in resources like memory regions, processor registers, or files, leading to loss of original content—a term formalized in and documentation to indicate that certain registers or memory are modified by code, requiring the compiler to treat them as unavailable for preservation. A related web security technique, known as , involves injecting to manipulate the and alter behavior without executable code. Culturally, the phrase "it's clobberin' time" gained prominence in American through the Marvel character Ben Grimm (The Thing), who uses it as a since the , reinforcing the term's association with forceful confrontation.

Introduction

Definition

Clobbering in refers to the act of overwriting a , such as a file, , or region, such that its original content is permanently lost unless backups or recovery mechanisms are in place. This process typically involves replacing in storage or temporary holding areas without preserving the prior state, leading to unintended consequences like or program failure. Clobbering manifests across hardware and software layers, from low-level CPU operations to high-level interactions, and is characterized by its irreversibility in the absence of safeguards. While clobbering is most commonly unintentional—arising from programming errors, such as buffer overflows that overwrite adjacent memory or accidental file redirections in shell environments—it can also be deliberate to achieve specific outcomes, like clearing build artifacts in software compilation processes. Unintentional clobbering often stems from operations that fail to account for existing data, exemplified by default behaviors in Unix-like systems where output redirection can overwrite files unless protected by options like noclobber. In contrast, intentional clobbering, such as invoking a "clobber" target in build tools, systematically erases generated files to ensure reproducibility and avoid incremental errors from prior builds. Affected resources include files on , where overwriting erases persistent data; processor registers, which serve as temporary CPU storage and can be explicitly declared as clobbered in inline assembly to inform compilers of modifications; and regions in RAM, where allocations may inadvertently overlap and destroy allocated data. These examples illustrate clobbering's broad impact, though specific mechanisms, like register usage in assembly or file operations in commands, vary by context.

Etymology and Historical Usage

In , "clobber" entered through 1970s hacker culture at institutions like MIT's AI Lab, where the —a of technical terminology—first documented it around 1975 as a meaning to overwrite unintentionally, often in reference to memory or storage mishaps like "clobber the stack." This usage reflects the earlier sense of "clobber" meaning to hit hard or defeat decisively, which originated in British around 1941, likely in contexts during . Synonymous with terms like "mung" (to destroy or modify badly) or "trash," it captured the destructive impact of programming errors in resource-limited environments, evolving from mainframe systems where buffer overflows could corrupt critical regions. By the early 1980s, as personal computing proliferated, the term appeared in programming literature; for instance, a 1985 article in The Transactor magazine for Commodore users warned that the Commodore 64's operating system, when moved to RAM, was subject to clobbering if memory was modified via POKE commands from BASIC or the monitor. The term's adoption drew on the metaphorical sense of forceful destruction from non-computing , aligning with computing's emphasis on , and persists into modern usage for overwriting files or registers. Its cultural endurance is evident in open-source documentation, such as the Compiler Collection (GCC) manuals since the project's 1987 inception, where "clobber" denotes registers or memory altered by inline assembly, ensuring compilers account for such modifications.

Clobbering in Command-Line Operations

File Redirection

In shell environments such as Bash, file redirection allows the output of commands to be directed to files, where the > operator overwrites the target file entirely if it exists, discarding its previous contents and potentially leading to . In contrast, the >> operator appends the output to the end of the file, preserving existing content. This overwriting behavior primarily affects standard output streams (stdout, file descriptor 1), but can also involve standard error (stderr, file descriptor 2) when redirected similarly. To mitigate accidental overwriting, Bash provides the noclobber option, enabled via the command set -o noclobber, which causes redirection attempts using > to fail if the target file already exists and is a regular file. When noclobber is active, users must explicitly force overwriting by using the >| operator, which bypasses the protection and truncates the file regardless. For example, executing echo "new data" > existing_file.txt in a standard Bash session will replace the entire contents of existing_file.txt with "new data", erasing any prior information. With noclobber enabled, the same command would result in an error, such as "bash: existing_file.txt: cannot overwrite existing file". This mechanism is commonly employed in scripting for tasks like , where output is redirected to files to record command results or errors, but it poses risks to if > is used inadvertently on important files. Best practices recommend using >> for to entries without clobbering historical data, thereby maintaining script reliability in production environments.

Copy and Move Commands

In operating systems, the cp command, used for copying files and directories, overwrites the destination file by default if it already exists, without prompting the user. To mitigate clobbering risks, the -i flag enables interactive mode, prompting before overwriting an existing destination, while the -n or --no-clobber flag prevents overwriting altogether by skipping the operation if the destination exists. For example, executing cp source.txt dest.txt will silently replace the contents of dest.txt with those from source.txt if dest.txt exists. The mv command, which moves or renames files and directories, also clobbers the destination by default, replacing it without prompting unless specified otherwise. This replacement is atomic when the source and destination are on the same filesystem, as mv leverages the underlying rename(2) to swap the names instantaneously, ensuring no partial states. The -i flag adds interactivity by prompting before overwriting, and in implementations, the -n or --no-clobber flag prevents overwriting; POSIX-compliant minimal implementations and some BSD variants (e.g., , ) lack this option, requiring scripting or existence checks instead. An example is mv old.txt new.txt, which will atomically replace new.txt with old.txt if new.txt exists, effectively deleting the original content of new.txt. These behaviors are consistent across Unix-like platforms such as and macOS, where cp and mv follow standards with or BSD implementations. In contrast, Windows Command Prompt equivalents like the copy and move commands prompt for confirmation before overwriting by default, with the /Y switch suppressing prompts to enable silent clobbering.

Clobbering in Build Systems

Make

In Make, the clobber target is a commonly defined phony target that intentionally removes all generated files, intermediate objects, and outputs from previous builds to achieve a complete cleanup. Unlike the standard clean target, which typically deletes only build artifacts like object files (e.g., *.o) while preserving configuration files, clobber extends this to eliminate additional elements such as derived configuration or links, ensuring no remnants influence subsequent builds. This target is not built into Make but is a user-defined convention recommended in the documentation for thorough resets. To implement the clobber target, Makefile authors declare it as phony to prevent conflicts with any existing file named clobber and specify a recipe for deletion, often using shell commands like rm. For example:

.PHONY: clobber clobber: rm -f *.o $(EXECUTABLE) config.cache

.PHONY: clobber clobber: rm -f *.o $(EXECUTABLE) config.cache

This syntax ensures the target executes reliably every time it is invoked via make clobber, overwriting or removing files as needed without implicit rule interference. Developers often pair clobber with clean to provide graduated cleanup options: make clean for partial removal of intermediates and make clobber for a full wipe. The primary purpose of the clobber target is to facilitate by eliminating all artifacts that could introduce variability, such as platform-specific binaries or cached data, which has been a standard practice in software projects since the widespread adoption of Make in the . This approach helps debug build issues or prepare distributions free of prior state. Similar cleanup mechanisms appear in other build tools, though with varying syntax.

Other Build Tools

In build systems beyond GNU Make, clobbering mechanisms often emphasize declarative configurations and cross-platform compatibility, differing from Make's imperative rule-based approach where targets like clobber explicitly sequence file deletions. Tools such as CMake and Apache Ant provide structured ways to wipe build artifacts, supporting diverse project ecosystems like C++ and Java development. CMake, a cross-platform meta-build system, facilitates clobbering through built-in commands and generated build targets rather than direct imperative scripts. Developers commonly invoke make clean (or equivalent in generated build systems like Ninja) to remove object files and intermediates. In CMakeLists.txt scripts, the file(REMOVE_RECURSE) command enables recursive deletion of directories, such as build outputs, without errors for non-existent paths; this runs during the configuration phase to ensure a fresh start. For instance, to fully overwrite a build directory, one might use execute_process(COMMAND ${CMAKE_COMMAND} -E remove_directory ${CMAKE_BINARY_DIR}/build), which executes a shell-equivalent removal at configure time, preserving timestamps and handling platform variations. These methods suit C++ projects by abstracting platform-specific deletions, unlike Make's file-centric imperatives. Apache Ant, an XML-based build tool primarily for Java ecosystems, employs the <delete> task for clobbering build directories, offering declarative task definitions that parallel Make's clean or clobber but with finer resource collection control. The <clean> target typically orchestrates deletions, analogous to Make's clobber, by invoking <delete dir="${build.dir}"/> to remove entire directories and contents, including symbolic links, while ignoring default excludes for thorough wipes. For selective clobbering, the dir attribute in <delete> combined with nested <fileset> elements allows pattern-based removal, such as <delete><fileset dir="build" includes="**/*.class"/></delete>, enabling incremental cleans without full overwrites. This task-oriented style contrasts with CMake's script generation, providing cross-platform reliability in Java/C++ hybrid projects through verbose logging and dependency resolution.

Clobbering in Low-Level Programming

Registers in Assembly Language

In assembly language programming, particularly when embedding inline assembly within higher-level languages like C, clobbering refers to the modification of CPU registers in ways that are unpredictable to the compiler. Clobbered registers are those altered by the inline assembly code without explicit output operands, necessitating declaration to alert the compiler about these changes. This declaration prevents the compiler from making erroneous optimizations, such as assuming the register's value remains unchanged across the assembly block. Failure to declare clobbers can result in data corruption, incorrect program behavior, or even stack corruption if the compiler reallocates registers unexpectedly. The GNU Compiler Collection (GCC) provides extended inline assembly syntax to handle clobbers systematically. The basic structure is asm volatile ("assembly code" : output operands : input operands : clobber list), where the clobber list—a comma-separated series of string constants—specifies modified registers or resources. For instance, individual registers like "eax" can be listed to indicate they are overwritten, prompting the to avoid using them for other purposes without saving their values first. Special clobbers include "cc", which denotes modification of the condition code (flags) register, and "[memory](/page/Memory)", signaling that the assembly may read from or write to memory locations beyond the specified operands, thereby invalidating any cached memory assumptions by the . Consider an x86 example where inline assembly performs a bit scan on an input value:

c

int lowest_bit_set(int input) { int position; asm volatile ("bsf %1, %0" : "=r" (position) : "r" (input) : "cc"); return position; }

int lowest_bit_set(int input) { int position; asm volatile ("bsf %1, %0" : "=r" (position) : "r" (input) : "cc"); return position; }

Here, the clobber "cc" informs the that the is altered by the bsf instruction, ensuring subsequent code does not rely on unchanged flags. If "eax" were used implicitly and not declared, the might reuse it for another variable, leading to overwritten data; declaring it as a clobber avoids this by treating it as a scratch register. Another risk arises with undeclared memory accesses, as in:

c

asm volatile ("movl &#36;0, %0" : "=m" (some_var) : : "memory");

asm volatile ("movl &#36;0, %0" : "=m" (some_var) : : "memory");

The "memory" clobber forces the compiler to reload variables potentially affected by the store, preventing optimization errors like dead store elimination.

Memory Regions

In low-level programming languages such as C and C++, clobbering of memory regions occurs when operations inadvertently or maliciously overwrite data in adjacent or deallocated memory areas, often due to the absence of built-in bounds checking. This vulnerability is prevalent in stack and heap allocations, where improper handling of arrays or pointers can lead to corruption of critical data structures like return addresses or metadata. Buffer overflow clobbering on the stack happens when a program writes data beyond the allocated bounds of an , overwriting neighboring regions. For instance, in C, declaring char buf[10]; and then using strcpy(buf, "a very long string exceeding 10 bytes"); will overflow the buffer and potentially corrupt the stack frame, including saved registers or the function's . Unintentional overflows commonly arise in loops, such as int arr[5]; for(int i = 0; i < 10; i++) arr[i] = 42;, which writes past the array's end and clobbers subsequent stack variables or metadata. A notorious intentional exploitation is stack smashing, where an attacker overflows a buffer to overwrite the with malicious code, enabling arbitrary execution; this technique was detailed in early analyses of buffer overflow vulnerabilities. Heap clobbering involves corruption of dynamically allocated memory, often through double-free or use-after-free errors, where freed regions are reused or overwritten unexpectedly. In C/C++, calling free(ptr); free(ptr); on the same pointer constitutes a double-free, which can allow an attacker to allocate and overwrite the freed block's metadata, leading to further corruption during subsequent allocations. Use-after-free occurs when a pointer to deallocated memory is dereferenced, such as accessing ptr->field after free(ptr); without setting ptr = NULL;, potentially clobbering newly allocated data in that region. Tools like Valgrind's Memcheck detect these issues by tracking heap allocations and flagging invalid frees or accesses to uninitialized/freed memory. Such clobbering in memory regions frequently results in program crashes, data corruption, or exploitable security vulnerabilities, particularly in systems programming where manual memory management is required. These problems are exacerbated in languages like C and C++ that lack automatic bounds or ownership checking, making them a persistent challenge in software security.

Clobbering in Web Technologies

DOM Clobbering

is a client-side web security attack technique that involves injecting elements into a webpage to overwrite or "clobber" properties of objects, such as those on the window or document prototypes, thereby manipulating script behavior without injecting executable code. This method exploits the browser's DOM resolution mechanism, where elements with name or id attributes create named properties that shadow existing global variables or object members, leading to unexpected property access during script execution. The technique relies on collections—live lists of elements matching certain criteria—that can masquerade as original objects, altering their properties like href or attributes. The primary attack vector is through reflected, stored, or DOM-based injection points where user-controlled HTML is parsed into the document without proper sanitization, allowing attackers to insert elements that collide with sensitive JavaScript identifiers. For instance, injecting <a name="document" id="document"></a> can clobber the global document object, replacing it with an HTMLAnchorElement whose properties (e.g., href) may then be accessed by unsuspecting scripts. Another common example is <img name="location" src="x">, which shadows window.location with an HTMLImageElement, potentially enabling attackers to redirect users if a script assigns a malicious URL to location.href. These collisions affect named property lookups on the window and document objects across major browsers, including Chrome and Firefox, due to standardized DOM behaviors. The technique was first publicly described in 2013 by security researcher Gareth Heyes, who demonstrated its potential to disrupt assumptions about global objects and enable (XSS) in legacy browsers like . It gained further prominence in XSS research between 2019 and 2023, with notable exploits such as Michał Bentkowski's 2019 attack on using to bypass AMP for Email restrictions, and subsequent academic analyses revealing its prevalence in modern web applications. Studies from this period, including a 2023 evaluation across the top 5,000 websites, identified thousands of vulnerable data flows in production sites, highlighting its underappreciated role in client-side attacks. DOM clobbering's impacts include facilitating XSS by tricking applications into loading external malicious scripts, open redirects for attacks, and potential through manipulated property reads, all while evading content security policies (CSP) that block direct script injection. For example, clobbering configuration objects can lead to unauthorized script loads from attacker-controlled domains, compromising user sessions on affected sites. Real-world vulnerabilities have been reported in platforms like , , and , where it enables client-side request forgery or without traditional injection vectors. This underscores its threat to browser-based environments, where improper reliance on global object integrity can cascade into severe security breaches. DOM clobbering plays a significant role in DOM-based (XSS) attacks by enabling attackers to overwrite global variables, object properties, or browser APIs through injected elements, thereby facilitating the execution of malicious payloads without direct script injection. For instance, clobbering event handler properties or APIs like location allows redirection to attacker-controlled scripts or alteration of script sources, bypassing client-side filters that block traditional XSS vectors. Empirical studies indicate that DOM clobbering vulnerabilities are widespread, affecting approximately 9.8% of the top 5,000 Tranco websites, with 9,467 vulnerable data flows identified across 491 sites and 3,821 webpages. Notably, 38.8% of these vulnerabilities (3,677 data flows) can be exploited to achieve XSS, as observed in high-profile sites such as , , and . These issues persist in modern frameworks like React when user-controlled is not properly sanitized, as bundlers such as —commonly used in React ecosystems—have been found to introduce clobbering gadgets that lead to XSS in scriptless contexts. Common variants include ID clobbering, where elements like <a id="alert" name="alert"> shadow built-in functions such as alert(), enabling code execution by overriding expected behaviors. Another variant involves name-based clobbering on form elements, such as <form name="location" action="javascript:alert(1)">, which can hijack navigation or API calls. These techniques are frequently combined with open redirects, where clobbered location properties force browser navigation to malicious URLs, amplifying the attack surface in five documented cases from large-scale analyses. Detection of DOM clobbering often relies on dynamic analysis tools that simulate HTML injections and monitor DOM manipulations, such as OWASP ZAP's DOM XSS active scan rule, which flags potential clobbering by launching browser instances and testing payloads against relevant DOM sinks. Automated tools like TheThing employ hybrid program analysis on billions of JavaScript lines to identify exploitable gadgets, revealing 31,432 distinct clobbering markups across five techniques. Browser mitigations include JavaScript strict mode, which raises errors on undeclared variable assignments and read-only property overwrites, though it does not fully prevent DOM-level collisions; Content Security Policy (CSP) provides partial protection by restricting script sources but mitigates only 14.7% of known vulnerabilities. As of 2025, remains relevant, with new vulnerabilities reported in tools like (GHSA-4vvj-4cpr-p986, August 2024) and libraries such as Mavo (CVE-2024-53388, March 2025), enabling via crafted . Recent research, including papers at Security 2025 and ACM CCS 2025, advances detection and exploitation techniques for these gadgets in modern web applications.

Prevention and Mitigation

General Strategies

One fundamental strategy to mitigate clobbering involves implementing robust backups and versioning mechanisms, which enable recovery from unintended data overwrites across file systems and memory environments. In file-based contexts, version control systems such as track incremental changes to and data files, allowing developers to revert to previous states and prevent permanent loss from collaborative overwrites or errors. For memory management in low-level programming, techniques like memory snapshots capture the runtime state of processes, facilitating quick restoration if registers or regions are accidentally clobbered during execution. These approaches ensure that is maintained by providing a historical record or instantaneous checkpoint, reducing the impact of clobbering without altering core system behaviors. Adopting safe defaults in further minimizes the risk of clobbering by prioritizing non-destructive operations and built-in safeguards. Programming languages and libraries should default to modes for file operations rather than overwrite, as seen in standards like file handling, where flags such as O_APPEND prevent cursor repositioning that could lead to . Additionally, incorporating error checking routines—such as validating write operations before committing changes—helps detect potential clobbering early, promoting resilience in both build processes and runtime environments. This principle of "secure by default" extends to APIs and tools that avoid global pollution, ensuring that modifications require explicit intent. Comprehensive testing practices are essential for identifying and averting clobbering vulnerabilities before deployment. Unit tests focused on , including boundary checks for buffers and registers, can simulate overwrite scenarios to verify data preservation, while fuzz testing introduces random inputs to uncover hidden paths. Static analysis tools complement this by scanning code for patterns indicative of potential overwrites, such as unhandled error variables being reassigned, enabling proactive fixes in large codebases. These methods prioritize early detection, aligning with guidelines from organizations like CISA that emphasize rigorous verification to enhance overall system reliability. Raising awareness through and forms the of clobbering prevention, fostering a culture of caution among developers. programs on data loss risks highlight common pitfalls like unintended register clobbering in assembly or file overwrites in scripts, drawing from resources that stress the consequences of memory-unsafe practices. Clear of intentional clobbering operations—such as in build targets or optimization flags—ensures teams understand and control when data destruction is deliberate, avoiding accidental repetition. By integrating these awareness efforts into development workflows, organizations can reduce human-error-induced clobbering across diverse computing domains.

Context-Specific Techniques

In shell environments like Bash, enabling the noclobber option via set -o noclobber prevents output redirection from overwriting existing files, thereby mitigating accidental clobbering during script execution. This shell builtin, part of the standard, ensures that attempts to redirect to an existing file result in an error unless explicitly overridden with >|. Complementing this, developers can verify target file existence using conditional checks, such as if [[ ! -f target.txt ]]; then > target.txt; fi, before performing redirections to add an extra layer of safety. For build systems, Makefiles can incorporate phony targets to avoid conflicts where a target name matches an existing file, which could lead to unintended overwrites or skipped builds; declaring .PHONY: [clean](/page/The_Clean) ensures the clean rule executes regardless of file presence. In GNU Make, this practice improves reliability by distinguishing abstract actions from file dependencies. Similarly, in , conditional deletes during clean operations—implemented via custom commands like if(EXISTS "${CMAKE_BINARY_DIR}/output") file(REMOVE "${CMAKE_BINARY_DIR}/output") endif()—prevent indiscriminate clobbering of generated artifacts while allowing targeted removal. In low-level programming, inline assembly code must explicitly declare all clobbered registers and memory in the clobber list to inform the compiler of modifications, as per GCC's extended ASM syntax; for example, asm volatile ("mov %0, %%eax" : "=r"(result) : "r"(input) : "eax", "memory"); ensures the compiler preserves non-clobbered state. To prevent buffer clobbering in C string operations, functions like strncpy(dest, src, sizeof(dest)) should replace strcpy by limiting copies to the destination buffer size, avoiding overflows that corrupt adjacent memory; this aligns with secure coding guidelines from the CERT C Coding Standard, which emphasize bounded operations to maintain program integrity. In web technologies, particularly for , input sanitization using libraries like DOMPurify removes or escapes dangerous attributes such as id and name from user-supplied before insertion, blocking property overwrites on global objects like window. Employing subdomains for isolates origins, preventing cross-frame clobbering via enforcement. Additionally, code should check property existence with if ('property' in window && window.property === expectedValue) before access to detect and handle potential clobbering. Browser configurations, such as Content-Security-Policy (CSP) headers with directives like script-src 'self', restrict script sources and mitigate injection-based clobbering by blocking unauthorized code execution.

References

  1. https://dictionary.cambridge.org/us/dictionary/english/clobbering
  2. https://www.merriam-webster.com/dictionary/clobber
  3. https://www.dictionary.com/browse/clobber
  4. https://www.collinsdictionary.com/us/dictionary/english/clobber
  5. https://www.etymonline.com/word/clobber
  6. https://en.wiktionary.org/wiki/clobber
  7. https://www.britannica.com/dictionary/clobber
  8. https://daily.wordreference.com/2024/10/11/intermediate-word-of-the-day-clobber/
  9. https://www.computer-dictionary-online.org/definitions-c/clobber
  10. https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
  11. https://portswigger.net/web-security/dom-based/dom-clobbering
  12. https://www.merriam-webster.com/thesaurus/clobbering
  13. http://www.catb.org/jargon/html/C/clobber.html
  14. https://foldoc.org/clobber
  15. https://www.cyberciti.biz/tips/howto-keep-file-safe-from-overwriting.html
  16. https://www.geeksforgeeks.org/linux-unix/how-to-protect-linux-shell-file-using-noclobber-in-bash-shell/
  17. https://www.cs.princeton.edu/courses/archive/fall07/cos217/precepthandouts/15/MakeTutorial.pdf
  18. http://catb.org/jargon/html/C/clobber.html
  19. https://www.commodore.ca/wp-content/uploads/2015/12/the_transactor_vol05_04_1985_jan-www-commodore-ca.pdf
  20. https://www.gnu.org/software/bash/manual/bash.html#Redirections
  21. https://www.gnu.org/software/bash/manual/bash.html#Appending-Redirected-Output
  22. https://www.baeldung.com/linux/logging-bash-scripts
  23. https://www.gnu.org/software/coreutils/manual/html_node/mv-invocation.html
  24. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/copy
  25. https://www.gnu.org/software/make/manual/html_node/Goals.html
  26. https://www.gnu.org/software/make/manual/html_node/Phony-Targets.html
  27. https://www.gnu.org/software/make/manual/html_node/Standard-Targets.html
  28. https://ant.apache.org/manual/using.html
  29. https://cmake.org/cmake/help/latest/command/file.html
  30. https://ant.apache.org/manual/Tasks/delete.html
  31. https://ant.apache.org/manual/tutorial-HelloWorldWithAnt.html
  32. https://www.cs.utexas.edu/~ojensen/courses/cs361s/notes/memattacks.pdf
  33. https://people.eecs.berkeley.edu/~raluca/cs261-f15/beyondsmashing.pdf
  34. https://repository.fit.edu/cgi/viewcontent.cgi?article=1780&context=etd
  35. https://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf
  36. https://www.seclab.cs.sunysb.edu/seclab/pubs/usenix03.pdf
  37. https://www2.eecs.berkeley.edu/Pubs/TechRpts/2017/EECS-2017-209.pdf
  38. https://valgrind.org/docs/manual/mc-manual.html
  39. https://www.usenix.org/system/files/osdi23-gopal.pdf
  40. https://cheatsheetseries.owasp.org/cheatsheets/DOM_Clobbering_Prevention_Cheat_Sheet.html
  41. https://portswigger.net/research/dom-clobbering-strikes-back
  42. https://cispa.de/en/research/publications/71734-it-s-dom-clobbering-time-attack-techniques-prevalence-and-defenses
  43. https://www.htmhell.dev/adventcalendar/2022/12/
  44. https://trouge.net/papers/domclob_sp23.pdf
  45. https://thespanner.co.uk/2013/05/16/dom-clobbering/
  46. https://ieeexplore.ieee.org/document/10179403/
  47. https://github.com/rollup/rollup/security/advisories/GHSA-gcx4-mw62-g8wm
  48. https://www.zaproxy.org/docs/desktop/addons/dom-xss-active-scan-rule/
  49. https://github.com/webpack/webpack/security/advisories/GHSA-4vvj-4cpr-p986
  50. https://nvd.nist.gov/vuln/detail/CVE-2024-53388
  51. https://www.usenix.org/system/files/usenixsecurity25-liu-zhengyu.pdf
  52. https://dl.acm.org/doi/10.5555/3766078.3766503
  53. https://www.perforce.com/blog/vcs/what-is-version-control
  54. https://modal.com/blog/mem-snapshots
  55. https://www.parasoft.com/learning-center/static-code-analysis-guide/
  56. https://devguide.owasp.org/en/04-design/02-web-app-checklist/01-secure-by-default/
  57. https://www.code-intelligence.com/blog/memory_safety_corruption
  58. https://web.cs.ucdavis.edu/~rubio/includes/ghc11.pdf
  59. https://www.cisa.gov/sites/default/files/2024-06/joint-guidance-exploring-memory-safety-in-critical-open-source-projects-508c.pdf
  60. https://www.ibm.com/think/insights/data-protection-strategy
  61. https://www.securityjourney.com/post/top-10-insecure-software-development-techniques-to-avoid-and-what-to-do-instead
Add your contribution
Related Hubs
User Avatar
No comments yet.