HAHWUL

Hello SmuggleX 👋🏼

2025-12-27T00:00:00+00:00

Hello! I've recently released a new tool I've been working on and shared it via 𝕏</a>. It's called smugglex, a tool designed to detect HTTP Request Smuggling.

https://github.com/hahwul/smugglex</a>

Installation</h2>
It currently supports installation through various package managers like Homebrew, Snapcraft, Nix, Cargo, and more. Please refer to the Installation documentation</a> and install using your preferred method.
# e.g., cargo install smugglex brew install hahwul/smugglex/smugglex nix profile install github:hahwul/smugglex </code></pre> For reference, I plan to align support for these package managers across all the tools I develop. Nix and others are already supported in recently updated tools (noir, smugglex), and dalfox (already applied in the v3 codebase), urx, and other tools will provide similar installation methods in the future. Detect Smuggling</h2> This tool primarily aims to detect HTTP Request Smuggling. You can perform scans as shown below, targeting either a single target or multiple targets. # Single target smugglex https://target.com # Multiple targets cat urls.txt | smugglex </code></pre> If smuggling is detected, it provides a sample request that you can use for testing, as shown below. Exploiting</h2> smugglex currently provides 2 exploit methods. When using this feature, it performs additional tests upon detecting smuggling. EXPLOIT: -e, --exploit <EXPLOIT> Exploit types to run after detection (comma-separated: localhost-access,path-fuzz) </code></pre> For localhost-access, it performs functions to access various localhost information through smuggled requests. [*] Testing localhost access on port 80... [*] Generated localhost payload for port 80 --- REQUEST --- POST / HTTP/1.1 Host: 0a1100f0035b6b6380e0c60e005c00c4.web-security-academy.net Connection: keep-alive Content-Length: 6 Transfer-Encoding: chunked 1 X 0 GET / HTTP/1.1 Host: 127.0.0.1:80 Connection: close </code></pre> path-fuzz explores backend paths using smuggled requests with a predefined list or a user-provided list (--exploit-wordlist</code>). Next Plan</h2> In fact, after sharing it, I've received a lot of interest and feedback via DMs. While features are important, for now, my priority is improving smuggling detection performance (increasing true positives and reducing false positives). I'll continue expanding the exploit section, and ultimately, I hope it evolves beyond a simple scanner into a tool that covers the entire process of testing HTTP Request Smuggling. If you try it out and have any suggestions for improvements, please feel free to let me know. The year is already coming to an end! Wishing everyone a happy new year with lots of good fortune!

Red, Blue, Purple in Offensive Security 2025-10-05T00:00:00+00:00 I work as a security engineer in a corporate Red Team position. What most people imagine is "people who hack systems in flashy ways,” but the reality of working inside a company is much more complex. Is a corporate Red Team truly able to operate as a Red Team? To be blunt, I don’t think so. Today, I’d like to share my thoughts on the relationship between Red, Blue, and Purple Teams, and the struggles that come with it. Red, Blue, Purple</h2> Red, Blue, and Purple are the most common categories used in cybersecurity. Teams that perform penetration testing or offensive operations are called Red Teams. Departments responsible for defense, like CERT or internal monitoring, are called Blue Teams. When these two collaborate closely, the result is the concept of a Purple Team. Some also expand this idea into Yellow, Green, or Orange Teams to define other security functions. I belong to a Red Team, but within the boundaries of a company, it’s not easy to operate in a truly "Red” way. Red Team in Company</h2> The purpose of having a security team in a company is ultimately to strengthen security. Naturally, this tends to lean toward Blue objectives. Even when we use offensive techniques, the end result looks more Purple—or even closer to Indigo. For example, even if we find a vulnerability, it doesn’t just end with "This can be exploited.” We have to write reports, suggest mitigations tailored to the service, and even discuss architectural adjustments. Before long, this work feels closer to that of a general security engineer rather than a pure Red Teamer. That’s why I think it’s difficult to maintain a truly pure Red Team in a corporate environment. From Red to Indigo</h2> Our skills may be Red, but the environment pushes us toward Purple, and eventually into Indigo. Red Team members—Offensive Security Engineers—are faced with this reality. If we simply adapt, we’ll gradually become more Blue, but it’s possible to maintain balance. On a personal level, that means consistently researching and studying to avoid losing touch with offensive skills. On an organizational or cultural level, it means creating opportunities to do more genuinely "Red” work. Recently, due to various security incidents in Korea, Red Teams are receiving more recognition. Some companies are even creating positions dedicated to genuine Red Team functions. I see this as a positive sign. Go Purple?</h2> By default, security engineers within a company inevitably lean toward the Blue Team side. In that situation, aiming for Purple often feels like heading further into Indigo. That’s why I believe that "to truly become a Purple Teamer, you first need to go deeper into Red." A solid Red foundation is the only way to create a proper Purple balance. After more than 10 years in this field, I feel that the offensive side of my work has gradually been shrinking each year. Of course, my ability to find vulnerabilities and my penetration skills have improved compared to before—but still, something feels lacking. I have plenty to do until the end of the year (mostly development work, of course), but these thoughts will probably stay with me. There isn’t a simple answer, but for me, it comes down to one thing: never letting go of Red. Red, Blue, Purple by Gemini Beginner’s Guide: Creating Your First Ruby Project 2025-09-21T00:00:00+00:00 Getting started with Ruby is quick if you follow a few simple steps. In this guide, you’ll install Ruby, scaffold a new gem project, write a tiny program, run tests, and produce a gem build. I’ll keep it minimal and practical so you can get productive fast. 1) Install Ruby</h2> Using RVM (Ruby Version Manager, macOS/Linux):</li> </ul> curl -sSL https://get.rvm.io | bash -s stable source ~/.rvm/scripts/rvm </code></pre> Install Ruby:</li> </ul> rvm install ruby --latest rvm use ruby --default </code></pre> Verify:</li> </ul> ruby --version gem --version bundler --version </code></pre> 2) Create a new project</h2> Ruby uses bundler</code> for dependency management and project scaffolding. Gem library:</li> </ul> bundle gem my_gem cd my_gem </code></pre> This creates a basic structure: my_gem/ ├─ Gemfile ├─ lib/ │ └─ my_gem.rb ├─ my_gem.gemspec └─ spec/ └─ my_gem_spec.rb </code></pre> 3) Write your first program</h2> Open lib/my_gem.rb</code> and define a simple module: module MyGem def self.greet(name = "Ruby") "Hello, #{name}!" end end </code></pre> Run it: ruby -e "require_relative 'lib/my_gem.rb'; puts MyGem.greet" </code></pre> 4) Manage dependencies</h2> If you add dependencies to Gemfile</code>, install them: bundle install </code></pre> You generally won’t need this for the very first “hello world,” but it’s essential once you pull in libraries like HTTP clients or web frameworks. 5) Format your code</h2> Install and use RuboCop: gem install rubocop </code></pre> Lint:</li> </ul> rubocop </code></pre> Auto-fix:</li> </ul> rubocop -a </code></pre> 6) Add a simple test (RSpec)</h2> Edit spec/my_gem_spec.rb</code>: require "my_gem" RSpec.describe MyGem do it "greets with default name" do expect(MyGem.greet).to eq "Hello, Ruby!" end it "greets a custom name" do expect(MyGem.greet("World")).to eq "Hello, World!" end end </code></pre> Run tests: bundle exec rspec # or verbose: bundle exec rspec -v </code></pre> 7) Build a gem</h2> Build your gem: gem build my_gem.gemspec </code></pre> Test install: gem install ./my_gem-0.1.0.gem </code></pre> 8) Check dependencies graph (nice debugging tool)</h2> bundle viz </code></pre> 9) Optional: Lint with RuboCop</h2> As mentioned, for more config: rubocop --auto-gen-config </code></pre> Visual overview</h2> Here’s a simple flow of your first project: flowchart LR A[Install Ruby] --> B[bundle gem my_gem] B --> C[Edit lib/my_gem.rb] C --> D[ruby run] D --> E[bundle exec rspec] E --> F[rubocop] F --> G[gem build] G --> H[gem install] </pre> What’s next?</h2> Explore popular gems: Web frameworks: Sinatra, Rails</li> Testing: RSpec</li> HTTP client: Faraday</li> </ul> </li> Build a gem, a CLI tool, or a Rails app and publish it on RubyGems.</li> </ul> You’ve just created, tested, and built your first Ruby gem. Keep it small, iterate quickly, and enjoy the flexibility of Ruby. Beginner’s Guide: Creating Your First Rust Project 2025-09-21T00:00:00+00:00 Getting started with Rust is quick if you follow a few simple steps. In this guide, you’ll install Rust, scaffold a new project, write a tiny program, run tests, and produce a release build. I’ll keep it minimal and practical so you can get productive fast. 1) Install Rust</h2> Official installer (works on all platforms):</li> </ul> curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh </code></pre> Verify</li> </ul> rustc --version cargo --version </code></pre> 2) Create a new project</h2> Rust uses cargo</code> for building, testing, and dependency management. Binary app (recommended for CLI apps and services):</li> </ul> cargo new hello_rust cd hello_rust </code></pre> This creates a basic structure: hello_rust/ ├─ Cargo.toml └─ src/ └─ main.rs </code></pre> 3) Write your first program</h2> Open src/main.rs</code> and print a greeting: fn main() { println!("Hello, Rust!"); } </code></pre> Run it: cargo run </code></pre> 4) Manage dependencies (when you need them)</h2> If you add dependencies to Cargo.toml</code>, build to install them: cargo build </code></pre> You generally won’t need this for the very first “hello world,” but it’s essential once you pull in crates like HTTP clients or web frameworks. 5) Format your code</h2> Rust ships a formatter: cargo fmt </code></pre> Run it from the project root to format all sources. 6) Add a simple test</h2> For a beginner-friendly pattern, wrap your code in a module and test it: // src/main.rs mod hello_rust { pub fn greet(name: &str) -> String { format!("Hello, {}!", name) } } fn main() { println!("{}", hello_rust::greet("Rust")); } #[cfg(test)] mod tests { use super::*; #[test] fn test_greet_default() { assert_eq!(hello_rust::greet("Rust"), "Hello, Rust!"); } #[test] fn test_greet_custom() { assert_eq!(hello_rust::greet("World"), "Hello, World!"); } } </code></pre> Run tests: cargo test # or verbose: cargo test -- --nocapture </code></pre> 7) Build a binary</h2> Two common ways to build: Debug build:</li> </ul> cargo build </code></pre> Release build:</li> </ul> cargo build --release </code></pre> Run your binary: ./target/debug/hello_rust # debug ./target/release/hello_rust # release </code></pre> 8) Check dependencies graph (nice debugging tool)</h2> cargo tree </code></pre> 9) Optional: Lint with Clippy</h2> Clippy is Rust’s official linter. Lint:</li> </ul> cargo clippy </code></pre> Auto-fix:</li> </ul> cargo clippy --fix </code></pre> Visual overview</h2> Here’s a simple flow of your first project: flowchart LR A[Install Rust] --> B[cargo new hello_rust] B --> C[Edit src/main.rs] C --> D[cargo run] D --> E[cargo test] E --> F[cargo fmt] F --> G[cargo build --release] G --> H[Run ./target/release/hello_rust] </pre> What’s next?</h2> Explore popular crates: Web frameworks: Rocket, Actix-Web</li> CLI: clap</li> HTTP client: reqwest</li> </ul> </li> Build a CLI tool, a web service, or a small library and publish it on crates.io.</li> </ul> You’ve just created, tested, and built your first Rust project. Keep it small, iterate quickly, and enjoy the safety and performance of Rust. Beginner’s Guide: Creating Your First Crystal Project 2025-09-16T00:00:00+00:00 Getting started with Crystal is quick if you follow a few simple steps. In this guide, you’ll install Crystal, scaffold a new project, write a tiny program, run tests, and produce a release build. I’ll keep it minimal and practical so you can get productive fast. 1) Install Crystal</h2> macOS (Homebrew)</li> </ul> brew install crystal </code></pre> Linux Check the official installation page for distro-specific instructions: https://crystal-lang.org/install/</li> </ul> </li> Verify </li> </ul> crystal --version shards --version </code></pre> Optional tools you’ll probably want soon: VS Code extension (Crystal + LSP): https://marketplace.visualstudio.com/items?itemName=crystal-lang-tools.crystal-lang</li> Linter (Ameba): https://marketplace.visualstudio.com/items?itemName=veelenga.crystal-ameba</li> </ul> 2) Create a new project</h2> Crystal uses shards</code> (like Ruby’s Bundler) for dependency management and project scaffolding. App template (recommended for CLI apps and services):</li> </ul> mkdir hello_crystal && cd hello_crystal shards init app hello_crystal </code></pre> Library template (if you’re building a shard/gem-like package):</li> </ul> mkdir my_lib && cd my_lib shards init lib my_lib </code></pre> This creates a basic structure (for an app): hello_crystal/ ├─ shard.yml └─ src/ └─ hello_crystal.cr </code></pre> 3) Write your first program</h2> Open src/hello_crystal.cr</code> and print a greeting: # src/hello_crystal.cr puts "Hello, Crystal!" </code></pre> Run it: crystal run src/hello_crystal.cr </code></pre> 4) Manage dependencies (when you need them)</h2> If you add dependencies to shard.yml</code>, install them with: shards install </code></pre> You generally won’t need this for the very first “hello world,” but it’s essential once you pull in libraries like HTTP clients or web frameworks. 5) Format your code</h2> Crystal ships a formatter: crystal tool format </code></pre> Run it from the project root to format all sources. 6) Add a simple test (spec)</h2> Create a spec file: # spec/hello_crystal_spec.cr require "spec" require "../src/hello_crystal" describe "hello_crystal" do it "runs without raising" do expect { Crystal.main }.not_to raise_error end end </code></pre> If your app doesn’t define Crystal.main</code>, you can test a function you write instead. For a beginner-friendly pattern, wrap your app code in a module: # src/hello_crystal.cr module HelloCrystal def self.greet(name : String = "Crystal") "Hello, #{name}!" end end puts HelloCrystal.greet </code></pre> And test it: # spec/hello_crystal_spec.cr require "spec" require "../src/hello_crystal" describe HelloCrystal do it "greets with default name" do HelloCrystal.greet.should eq "Hello, Crystal!" end it "greets a custom name" do HelloCrystal.greet("World").should eq "Hello, World!" end end </code></pre> Run tests: crystal spec # or verbose: crystal spec -v </code></pre> 7) Build a binary</h2> Two common ways to build: Using crystal directly:</li> </ul> crystal build --no-debug --release src/hello_crystal.cr -o bin/hello_crystal </code></pre> Using shards (works when shard.yml</code> defines targets):</li> </ul> shards build --no-debug --release </code></pre> Run your binary: ./bin/hello_crystal </code></pre> For production-like builds (strict dependencies and no dev deps): shards build --release --no-debug --production </code></pre> 8) Check dependencies graph (nice debugging tool)</h2> crystal tool dependencies ./src/hello_crystal.cr </code></pre> 9) Optional: Lint with Ameba</h2> Ameba is Crystal’s code style linter (similar to RuboCop). Install (macOS example):</li> </ul> brew tap crystal-ameba/ameba brew install ameba </code></pre> Lint:</li> </ul> ameba </code></pre> Auto-fix:</li> </ul> ameba --fix </code></pre> Visual overview</h2> Here’s a simple flow of your first project: flowchart LR A[Install Crystal] --> B[shards init app hello_crystal] B --> C[Edit src/hello_crystal.cr] C --> D[crystal run] D --> E[crystal spec] E --> F[crystal tool format] F --> G[shards build --release] G --> H[Run ./bin/hello_crystal] </pre> What’s next?</h2> Explore popular shards: Web frameworks: Kemal (Sinatra-like), Lucky and Amber (Rails-like)</li> Linting: Ameba</li> HTTP client: Crest</li> </ul> </li> Build a CLI tool, a web service, or a small library and publish it as a shard.</li> </ul> You’ve just created, tested, and built your first Crystal project. Keep it small, iterate quickly, and enjoy the speed and expressiveness of Crystal.How to Hack Web Assembly 2025-09-12T00:00:00+00:00 WebAssembly is a low-level assembly language that can process binary formats on the web. It runs on the web but feels like native execution, and can work together with JavaScript to achieve both high-performance processing and rapid implementation. This document outlines methods for testing and finding security vulnerabilities in WebAssembly applications. Structure</h3> WebAssembly Overview</h4> WebAssembly is a low-level assembly language that can process binary formats on the web. It works together with JavaScript and has the following characteristics: Near-native performance</li> Interoperability with JavaScript</li> Safe execution in browser sandbox environments</li> Compilable from various languages like C, C++, Rust, etc.</li> </ul> Basic Example</h4> #include <stdio.h> #include <sys/uio.h> #define WASM_EXPORT __attribute__((visibility("default"))) WASM_EXPORT int main(void) { printf("Hello World\n"); } /* External function that is implemented in JavaScript. */ extern void putc_js(char c); /* Basic implementation of the writev sys call. */ WASM_EXPORT size_t writev_c(int fd, const struct iovec *iov, int iovcnt) { size_t cnt = 0; for (int i = 0; i < iovcnt; i++) { for (int j = 0; j < iov[i].iov_len; j++) { putc_js(((char *)iov[i].iov_base)[j]); } cnt += iov[i].iov_len; } return cnt; } </code></pre> API Documents</h3> WebAssembly: https://webassembly.org/docs/</a></li> MDN WebAssembly: https://developer.mozilla.org/en-US/docs/WebAssembly</a></li> WebAssembly Text Format: https://webassembly.github.io/spec/core/text/index.html</a></li> </ul> Hack Mechanism</h2> WebAssembly operates the same way in each browser, creating an environment where both traditional binary attacks and web hacking techniques can be applied. Security Testing Points</h3> WebAssembly applications have the following security testing points: Traditional binary-related attacks: Known techniques like BOF, FSB, OOB can be applied, but WebAssembly has built-in security logic making techniques like ROP difficult.</li> Web attacks: The difference from existing web attacks is that web payloads or attack code can pass through the C layer.</li> Indirect function calls: When gaining JS control through XSS, the attack vectors expand significantly.</li> </ul> Code audit</h3> WebAssembly files typically have a .wasm</code> extension and are provided in binary format. For analysis, you need to decompile them and examine the related JavaScript code together. Find WASM files</h4> Methods to find WebAssembly files: Finding WebAssembly instances in JavaScript: Like SWF and ActiveX, since they're ultimately handled in JS, function or address information remains in the code. </li> Tracking WebAssembly loading functions: </li> </ol> // Using instantiateStreaming WebAssembly.instantiateStreaming(fetch('simple.wasm'), importObject) .then(results => { // Do something with the results! }); // Using XMLHttpRequest request = new XMLHttpRequest(); request.open('GET', 'simple.wasm'); request.responseType = 'arraybuffer'; request.send(); request.onload = function() { var bytes = request.response; WebAssembly.instantiate(bytes, importObject).then(results => { results.instance.exports.exported_func(); }); }; </code></pre> Browser Developer Tools: You can directly check wasm files in the Sources tab.</li> </ol> WASM File Structure</h4> WASM file headers start with .asm</code>: hexdump -C fail.wasm 00000000 00 61 73 6d 01 00 00 00 01 85 80 80 80 00 01 60 |.asm...........`| 00000010 00 01 7f 03 82 80 80 80 00 01 00 06 81 80 80 80 |................| 00000020 00 00 07 8b 80 80 80 00 01 07 66 61 69 6c 5f 6d |..........fail_m| 00000030 65 00 00 0a 8d 80 80 80 00 01 87 80 80 80 00 00 |e...............| 00000040 41 01 41 00 6d 0b |A.A.m.| 00000046 </code></pre> Decompile WASM & find info</h4> Installing tools for WASM decompilation: git clone --recursive https://github.com/WebAssembly/wabt apt install clang # (if clang is not available) make </code></pre> Object dump: ./wasm-objdump -xd fail.wasm fail.wasm: file format wasm 0x1 Section Details: Type[1]: - type[0] () -> i32 Function[1]: - func[0] sig=0 <fail_me> Global[0]: Export[1]: - func[0] <fail_me> -> "fail_me" Code Disassembly: 00003a <fail_me>: 000040: 41 01 | i32.const 1 000042: 41 00 | i32.const 0 000044: 6d | i32.div_s 000045: 0b | end </code></pre> Decompile to C: ./wasm2c fail.wasm </code></pre> Live audit</h3> Test with devtools</h4> You can access WebAssembly objects in the browser's developer tools: // Check WebAssembly object WebAssembly // CompileError: function CompileError() // Global: function Global() // Instance: function Instance() // LinkError: function LinkError() // Memory: function Memory() // Module: function Module() // RuntimeError: function RuntimeError() // Table: function Table() // compile: function compile() // compileStreaming: function compileStreaming() // instantiate: function instantiate() // instantiateStreaming: function instantiateStreaming() // validate: function validate() </code></pre> Function testing</h4> You can directly call WASM functions from JavaScript for testing. This is identical to SWF or ActiveX analysis methods. A major weakness</h3> Memory Safety Issues</h4> While WebAssembly provides memory safety, the following vulnerabilities can still occur: Buffer overflow in linear memory</li> Integer overflow/underflow</li> Out-of-bounds memory access</li> </ul> JavaScript Interface Vulnerabilities</h4> Vulnerabilities that can occur at the interface between WASM and JavaScript: Type confusion in parameter passing</li> Improper input validation</li> Memory corruption through shared memory</li> </ul> SOP (Same-Origin Policy) Issues</h4> When fetching WASM files using fetch, etc., the browser's SOP is forcibly applied: fetch('https://www.hahwul.com') // Cross-origin request blocked: Same-origin policy blocks remote resources </code></pre> However, since WASM can pass data to JavaScript: Check CORS application scope for potential SOP bypass</li> Verify if file upload is possible on the same domain (possibility of loading attacker-reconstructed WASM files)</li> </ul> 🛠 Environment</h2> Essential Tools</h3> WABT (WebAssembly Binary Toolkit): git clone --recursive https://github.com/WebAssembly/wabt make </code></pre> Included tools: wasm-objdump</code>: WASM file structure analysis</li> wasm2c</code>: Decompile WASM to C code</li> wasm2wat</code>: Convert WASM to text format</li> wat2wasm</code>: Convert text format to WASM</li> </ul> Emscripten: git clone https://github.com/emscripten-core/emsdk.git cd emsdk ./emsdk install latest ./emsdk activate latest </code></pre> Browser DevTools: All major browsers support WebAssembly debugging Testing Methodology</h3> Static Analysis: WASM file analysis using WABT tools</li> Dynamic Analysis: Runtime analysis through browser developer tools</li> Interface Testing: Data flow analysis between JavaScript-WASM</li> Memory Analysis: Linear memory access pattern verification</li> </ol> Articles</h2> How to analyze security vulnerabilities in WebAssembly?</a></li> </ul> References</h2> WebAssembly Security</a></li> BlackHat WebAssembly Paper</a></li> MDN WebAssembly</a></li> WebAssembly Binary Toolkit</a></li> </ul> OWASP Seoul Meetup 2025-09-07T00:00:00+00:00 At the recent OWASP Seoul</a> Meetup, I had the opportunity to speak on the topic of open source. I was a bit worried that it might be a familiar topic and lead to a mundane discussion, but thanks to the enthusiastic attendees, it turned out to be a truly memorable time. Both work and personal life have been so busy that time flew by quickly. Though a bit late, I’m jotting down some memories from that day. #1</h2> First, the passion at the venue was truly impressive. Despite the hot weather and the evening timing, I was deeply moved by everyone who took the time to attend. After the event, someone in the open chat room said, I'm super pumped! Gonna head home and jump straight into GitHub!</code> which actually gave me the spark to get fired up. Thanks to that, I’ve been making a lot of commits and releases lately. :D </div> </div> Though there wasn’t much time after my presentation, I had the chance to chat with various people. To be honest, it was a time where I gained a lot myself. #2</h2> Personally, I felt my presentation left something to be desired, but listening to the next talk, “Gather in the Forest of Translation,” completely washed away those thoughts. I thoroughly enjoyed the presentation, and I could relate to the pain points about reviews (though in my case, it’s not people but Agents 🤣). I picked up a few useful tricks from it. Also, I’m cheering for the ongoing PR</a>! #3</h2> Lastly, I want to express my heartfelt gratitude to the OWASP Seoul Chapter for organizing this wonderful opportunity and to everyone who attended. I also want to give another big thank you to Simon</a> for leaving such great comments for the Korean security/open-source community. I’ll make sure to attend again from time to time, so let’s meet at the next one! Thank you for the gift! Search in Zola: Fuse.js vs. Elasticlunr.js 2025-07-26T00:00:00+00:00 Zola is a fast and lightweight static site generator. To implement client-side search functionality without a server, you need a suitable JavaScript library. Zola supports generating index formats based on Fuse and Elasticlunr for search, making it easy to implement search features. Both are lightweight and operate without dependencies, but they differ in Korean language support and ease of use. In this article, I'll discuss the features, performance, Korean support of these two libraries, and why I chose Fuse.js. What is Fuse.js and Elasticlunr.js?</h2> To add search functionality in Zola, you need a client-side JavaScript library. Fuse.js and Elasticlunr.js are popular options, each strong in fuzzy search and full-text search, respectively. Library</th> Features</th> Pros/Cons</th></tr></thead> Fuse.js</td> Library specialized in fuzzy search</td> Pros: Strong in handling typos or partial matches, simple setup for quick implementation Cons: Does not support complex search features</td></tr> Elasticlunr.js</td> Supports full-text search</td> Pros: Provides advanced features like Boolean queries, TF/IDF ranking Cons: Requires additional setup for Korean search</td></tr> </tbody></table> Why Compare These Two?</h2> Search functionality for blogs or documents should be simple yet support multiple languages well. Both libraries are appealing because they work without dependencies and can be easily integrated with Zola's Tera templates and JavaScript. However, for me, the key factors in choosing were Korean search performance, ease of setup, and how well it aligns with Zola's simple philosophy. Fuse.js: Simple and Powerful Fuzzy Search</h3> Features: Easily indexes arrays or object lists by specifying keys like title</code>, content</code>. Flexible query adjustments are possible with search threshold or weights.</li> Korean Support: Naturally handles Korean fuzzy search without separate plugins. For example, searching for "한글" will find results like "한글 검색", "한글서치".</li> Performance: Operates quickly and lightly on small to medium-sized datasets (hundreds to thousands of documents).</li> </ul> e.g. const fuse = new Fuse(list, { keys: ['title', 'content'], threshold: 0.4 }); const results = fuse.search('한글'); </code></pre> Elasticlunr.js: Advanced Search Option</h3> Features: Supports field-specific indexing, stop word customization, Boolean queries, TF/IDF ranking. Precise search is possible with field-specific boosting (e.g., title:검색</code>).</li> Korean Support: Default settings are English-centric, so Korean search performance is poor. You need to add the lunr-languages</code> plugin for proper Korean tokenization.</li> Performance: Fast even on large datasets, but limited by browser memory, and setup is relatively complex.</li> </ul> e.g. const index = elasticlunr(); index.addField('title'); index.addDoc(doc); const results = index.search('한글', { fields: { title: { boost: 2 } } }); </code></pre> How to Integrate with Zola?</h2> Zola allows easy configuration of search UI with Tera templates and JavaScript. Depending on the config.toml</code> settings, a JSON format index file is generated during build, which can be loaded in JavaScript to add search functionality. Fuse</h3> Set index_format</code> to fuse_javascript</code> or fuse_json</code>, and during build, an index file in a format usable by Fuse.js, like search_index.en.json</code>, will be generated. # config.toml [search] index_format = "fuse_javascript" # or "fuse_json" </code></pre> Elasticlunr</h3> Similarly, set it to elasticlunr_javascript</code> or elasticlunr_json</code> to generate an index file in Elasticlunr format. # config.toml [search] index_format = "elasticlunr_javascript" # or "elasticlunr_json" </code></pre> My Case</h3> I added more weight to title</code> and included body</code> and tags</code> in the search targets as follows. You can adjust the threshold</code> value to set search sensitivity. var options = { keys: [ { name: "title", weight: 2 }, { name: "body", weight: 1 }, { name: "tags", weight: 1 }, ], includeScore: true, ignoreLocation: true, threshold: 0.4, // Adjust as needed for search sensitivity }; var currentTerm = ""; var documents = Object.values(window.searchIndex.documentStore.docs); var fuse = new Fuse(documents, options); // https://github.com/hahwul/goyo/blob/main/static/goyo.js </code></pre> Why I Chose Fuse.js</h2> Initially, since Zola didn't directly support Korean indexes, I was using Elasticlunr, which only worked for English searches. However, in May of this year (2025.05), the PR</a> I submitted was merged, officially enabling Korean index support, and it was included in a recent release. This led me to reconsider search libraries, and ultimately, I leaned towards Fuse.js because it aligns well with Zola's simple philosophy. The fact that the Fuse.js community is much more active was also appealing. Additionally, while lunr-language</code> supports Korean, integrating it with Elasticlunr.js requires a lot of effort, whereas Fuse.js can be used immediately without separate setup, making it convenient. Conclusion</h2> If you're implementing search functionality in Zola, I recommend Fuse.js as a simple and fast solution. It's especially optimal for small to medium-sized sites, providing flexible fuzzy search for Korean without additional setup. Elasticlunr.js is useful where advanced search features are needed, but in most cases, I think Fuse offers better value for the investment. Both libraries are excellent, but in my experience, Fuse.js fits better with Zola's conciseness. If you're running a blog or documentation page, I hope you'll compare various search features and create an even better search experience. Goyo 2025-07-12T00:00:00+00:00 Goyo is a Zola theme that aims for simplicity and clean documentation. Github</a> Demo & Docs</a> Dalfox 2.12 Released ⚡︎ 2025-07-06T00:00:00+00:00 Dalfox v2.12.0 has been released. It's been about three months since the previous version, 2.11, and this update includes various feature enhancements. Today, I'll briefly go over the new features that have been added. Added advanced XSS scanning features</h2> Four new flags have been added to improve the convenience and results of XSS scanning. I'd like to thank @ibrahmsql</a> for contributing these features. --detailed-analysis: Performs deeper parameter analysis to uncover more XSS vectors</li> --fast-scan: Enables faster scanning, useful in CI/CD pipelines</li> --magic-char-test: Generates magic character payloads for manual analysis</li> --context-aware: Selects payloads intelligently based on the response context</li> </ul> Improve help message (grouping)</h2> The readability of the --help</code> message has been improved. Options are now grouped by function, making it much cleaner and easier to read. --custom-blind-xss-payload flag</h2> Previously, only predefined values could be used for BSS (Blind XSS) payloads. Now, the --custom-blind-xss-payload</code> flag allows users to specify their own custom payloads. This is useful in environments that require a private C2 or a specific format. dalfox url http://test.com/?q=1 --custom-blind-xss-payload 'payloads.txt' </code></pre> New payload patterns</h2> Recently shared payloads have been added, such as those for codebase-based XSS. <object data=# codebase=javascript:alert(document.domain)//> <embed src=# codebase=javascript:alert(document.domain)//> </code></pre> Add markdown report format</h2> A markdown</code> (or md</code>) format has been added to the --report-format</code> option. You can now save scan results as a clean markdown report, making it easy to integrate into other documents. dalfox url "https://xss-game.appspot.com/level1/frame?query=AB" \ --report \ --report-format md </code></pre> This feature is especially useful when connecting to Caido. Please refer to the Dalfox Caido Integration</a> documentation. Server mode</h2> Here are the improvements for Server mode. API Key based authentication</h3> The --api-key</code> flag has been added to Server mode. By setting an API Key with this flag, you can operate the scanner more securely by only allowing requests that include the key in the X-API-Key</code> header. # Start Server dalfox server --api-key="SECRET" & # Scan curl --request POST \ --url http://localhost:6664/scan \ --header 'Content-Type: application/json' \ --header 'X-API-Key: SECRET' \ --data '{ "options": { "use-headless": true, "use-deepdxss": true, "output-all": true, "output-request": false, "output-response": false, "follow-redirects": true }, "url": "http://testphp.vulnweb.com/listproducts.php?artist=123" }' </code></pre> CORS, JSONP support</h3> Server mode now supports Cross-Origin Resource Sharing (CORS) and JSONP. The --allow-origins</code> and --jsonp</code> flags allow for more flexible integration of the Dalfox API with web applications from other domains. dalfox server \ --allow-origins "https://www.hahwul.com" \ --jsonp </code></pre> Pipe mode</h2> Here are the improvements for Pipe mode. Add raw HTTP request support to pipe mode</h3> Pipe mode now supports Raw HTTP Request as a direct input, just like File mode. This significantly improves interoperability, as you can directly pipe requests copied from proxy tools like Burp, Caido, and ZAP for testing. echo "POST https://www.hahwul.com/?q=dalfox HTTP/1.1 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ko-KR,ko;q=0.8,en-US;q=0.5,en;q=0.3 Connection: keep-alive Cookie: _ga=GA1.2.1102548207.1555467144; _gid=GA1.2.1362788908.1563875038 Upgrade-Insecure-Requests: 1 Host: www.hahwul.com asdf=asdf" | ./dalfox pipe --rawdata </code></pre> Bug Fixes & Dependency Updates</h2> Updated to a version of chromedp</code> where an upstream bug has been fixed. (It's recommended to update, as it was causing some errors).</li> Other minor bugs have been fixed, and dependency libraries have been updated.</li> </ul> Documentation</h2> The documentation has been improved in line with the updates. @fabaff</a>, who maintains dalfox in Nixpkgs, also contributed to the documentation updates. I'd like to thank him again. Next Plan</h2> In the future, Dalfox is planned to be improved in the following ways: Docs: We plan to overhaul the documentation to improve readability and accessibility.</li> Features from Issues: We will review various feature suggestions reported as GitHub issues and incorporate them into development.</li> New Mode: We are conceptualizing new scan modes, such as an Interactive mode that utilizes AI or proceeds with scans through user interaction.</li> </ul> Thank you to everyone who contributed to this release. This summer in korea is unusually hot, so I'll get to the next phase of work when the weather cools down a bit! Understanding DevSecOps 2025-06-25T00:00:00+00:00 What is DevSecOps?</h2> DevSecOps is a culture and methodology that integrates security throughout the entire development cycle while maintaining DevOps speed. As a Red Team, the most ideal scenario is a service built securely from the start, with no vulnerabilities to exploit. DevSecOps offers a practical solution to achieve this. In the past, security was often applied after development was complete, creating inefficiencies similar to tearing down walls in a finished building. DevSecOps solves this problem through the 'Shift Left' concept, moving security activities to earlier stages of development. graph TD A[Plan] --> B(Code); B --> C{Build}; C --> D[Test]; D --> E(Release); E --> F[Deploy]; F --> G(Operate); G --> H{Monitor}; H --> A; subgraph Security in All Phases direction LR S1[Threat Modeling] -- in --> A; S2[SAST / SCA] -- in --> B; S3[SAST] -- in --> C; S4[DAST / IAST] -- in --> D; S5[Config Scan] -- in --> F; S6[Runtime Security] -- in --> G; end </pre> The key is automating and integrating security into every phase, from threat modeling at the planning stage to SAST during coding and DAST during testing. Why DevSecOps?</h2> Speed is the essence. In CI/CD environments with multiple deployments per day, security performed after development completion becomes a bottleneck. DevSecOps automates security verification and integrates it into the pipeline, maintaining development speed while ensuring security. Here are examples of security activities and tools that can be applied at each SDLC stage: Design: Threat modeling (e.g., OWASP Threat Dragon)</li> Develop: Real-time IDE scanning (e.g., SonarLint)</li> Build: SAST (Static Analysis), SCA (Open Source Analysis) (e.g., SonarQube, dependency-check)</li> Test: DAST (Dynamic Analysis) (e.g., OWASP ZAP)</li> Deploy: IaC and container image scanning (e.g., Trivy, tfsec)</li> </ul> How to measure maturity?</h2> After implementing DevSecOps, measuring maturity and continuously improving is essential. The OWASP DevSecOps Verification Standard (DSOVS)</a> provides a useful framework for this purpose. DSOVS offers specific maturity assessment criteria across various domains including organization, design, and implementation, helping to diagnose current levels and design improvement roadmaps. For example, you can check items like: Do all team members receive regular security training? (ORG-002)</li> Are security requirements defined and tracked during feature development? (REQ-002)</li> Is threat modeling performed during architectural changes? (DES-002)</li> Are security scans automated in the CI/CD pipeline? (IMP-003)</li> Are penetration tests conducted regularly? (VER-002)</li> </ul> Resources</h2> I maintain the hahwul/DevSecOps</a> project to organize and manage various related materials for personal reference. Conclusion</h2> The success of DevSecOps goes beyond tool adoption; it depends on cultural change. True value emerges when security becomes a shared responsibility of everyone creating the product, not just the job of a specific team. The offensive perspective of a Red Team and the defensive approach of DevSecOps ultimately converge toward the same goal: creating secure services. I hope this article provides a small help in starting your DevSecOps journey. Understanding Content Security Policy (CSP) 2025-06-23T00:00:00+00:00 What is Content Security Policy (CSP)?</h2> Content Security Policy (CSP) is a security mechanism that controls which resources a web page can load, preventing attacks like Cross-Site Scripting (XSS) and data injection. CSP uses HTTP headers to specify trusted content sources, blocking execution of malicious scripts in the browser. Why is CSP Important?</h2> Modern web applications use resources from multiple sources, creating attack opportunities. CSP mitigates these threats by: Prevents XSS Attacks: By specifying trusted script sources, CSP blocks malicious scripts from being injected and executed.</li> Prevents Data Exfiltration: It can restrict data transmission to specific domains, preventing sensitive information from being leaked.</li> Prevents Clickjacking: The frame-ancestors</code> directive controls how other sites can frame the page, thus preventing clickjacking attacks.</li> Prevents Mixed Content: It helps maintain a secure connection by preventing HTTP content from being loaded on HTTPS pages.</li> </ul> How Does CSP Work?</h2> The web server sends the Content-Security-Policy</code> HTTP header to the browser with directives that control resource loading: Content-Security-Policy: script-src 'self'; </code></pre> The browser enforces this policy, blocking non-compliant resources and optionally reporting violations. Key CSP Directives</h3> CSP provides these key directives: Directive</th> Description</th></tr></thead> default-src</code></td> Sets a default policy for many other directives. If a specific directive is not set, this value is used.</td></tr> script-src</code></td> Specifies valid sources for JavaScript code.</td></tr> style-src</code></td> Specifies valid sources for CSS stylesheets.</td></tr> img-src</code></td> Specifies valid sources for images.</td></tr> font-src</code></td> Specifies valid sources for fonts.</td></tr> media-src</code></td> Specifies valid sources for media files like audio and video.</td></tr> connect-src</code></td> Restricts origins that can be connected to using fetch</code>, XMLHttpRequest</code>, WebSocket</code>, EventSource</code>, etc.</td></tr> frame-src</code></td> Specifies valid sources that can be embedded as frames. (Deprecated, child-src</code> is recommended).</td></tr> child-src</code></td> Specifies valid sources for nested browsing contexts, such as web workers and frames.</td></tr> object-src</code></td> Controls valid sources for <object></code>, <embed></code>, and <applet></code> tags. It's recommended to set this to 'none'</code> for security reasons.</td></tr> frame-ancestors</code></td> Specifies valid parent origins that can embed the current page using frames, iframes, objects, embeds, or applets. This is crucial for defending against clickjacking attacks.</td></tr> report-uri</code> / report-to</code></td> Specifies a URL where the browser will send reports when a CSP violation occurs. report-to</code> is a newer directive that supports JSON-formatted reports and supersedes report-uri</code>.</td></tr> </tbody></table> Source Values</h3> Each directive can have source values such as: Source Value</th> Description</th></tr></thead> 'self'</code></td> Current origin only (same scheme, host, port).</td></tr> 'unsafe-inline'</code></td> Inline JavaScript and CSS (security risk).</td></tr> 'unsafe-eval'</code></td> Allows eval()</code> and similar (security risk).</td></tr> 'none'</code></td> No sources allowed.</td></tr> https://example.com</code></td> Specific domain.</td></tr> *.example.com</code></td> All subdomains of example.com.</td></tr> data:</code></td> Data URI scheme resources.</td></tr> nonce-<base64-value></code></td> Scripts/styles with specific nonce.</td></tr> sha256-<base64-value></code></td> Scripts/styles with matching hash.</td></tr> </tbody></table> How to Apply CSP</h2> Apply CSP in one of two ways: HTTP Header (recommended):</li> </ol> Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted-cdn.com";</code></li> Apache: Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted-cdn.com"</code></li> </ul> <meta></code> Tag (limited support):<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://trusted-cdn.com;"> </code></pre> Note: <meta></code> doesn't support frame-ancestors</code>, report-uri</code>, or sandbox</code> directives.</li> </ol> CSP Implementation Strategy</h2> Implement CSP gradually to avoid breaking functionality: Report-Only Mode: Test without enforcement</li> Start lenient, then tighten: Begin with permissive rules, gradually remove unsafe directives</li> Use nonces/hashes instead of 'unsafe-inline'</code></li> Monitor and update: Regularly review violation reports and adjust as needed</li> </ul> Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-violation-report-endpoint; </code></pre> Benefits of CSP</h2> Strong XSS Defense: Blocks untrusted script execution</li> Reduced Data Injection: Limits malicious data insertion</li> Clickjacking Protection: Controls framing via frame-ancestors</code></li> Enhanced Security Awareness: Improves resource visibility</li> </ul> Conclusion</h2> CSP is essential for modern web application security, protecting against XSS and other common attacks. Despite implementation complexity, its security benefits are substantial. Gradual implementation and ongoing monitoring will significantly improve your site's security posture. How to Securing GraphQL 2025-06-23T00:00:00+00:00 GraphQL provides superior flexibility and efficiency compared to traditional REST APIs by allowing clients to request exactly the data they need. However, this flexibility introduces unique security challenges. If not addressed properly, these can lead to data leaks, denial of service vulnerabilities, and privilege escalation issues. In this post, I'll explain the major security threats related to GraphQL and provide practical strategies to protect GraphQL-based applications. The core principle is implementing security controls not only at the network boundary but deep within the application logic as well. The GraphQL Request Lifecycle</h2> A secure GraphQL request processing flow includes several layers of validation and verification. graph TD A[Client Request] --> B{HTTP Middleware}; B --> C{Authentication}; C -- Authenticated --> D[Parse Query]; C -- Failed --> Z[Reject Request]; D --> E{Validation}; E -- Cost/Depth OK --> F[Execute Resolvers]; E -- Invalid Query --> Z; F -- For each field --> G{Authorization Check}; G -- Authorized --> H[Fetch Data]; G -- Unauthorized --> I[Return Null/Error]; H --> J[Format Response]; I --> J; J --> K[Return to Client]; subgraph "Pre-Execution" B C D E end subgraph "Execution" F G H I end </pre> Abusing Introspection</h2> Problem: Introspection allows clients to query the GraphQL schema itself, exposing all types, fields, queries, and mutations. While useful for development tools, it gives attackers a map of your API's entire structure.</li> Mitigation: Disable introspection in production environments. This is typically available as a configuration flag in your GraphQL server library. For example, in apollo-server</code>, you can set it when instantiating the server:</li> </ul> const server = new ApolloServer({ typeDefs, resolvers, introspection: process.env.NODE_ENV !== 'production' }); </code></pre> Denial of Service (DoS)</h2> Problem: Attackers can craft deeply nested or complex queries that consume excessive server resources, causing denial of service for legitimate users.</li> Mitigations: Query Depth Limiting: Restrict the maximum nesting level of queries. For example, reject queries nested more than 10 levels deep.</li> Query Cost Analysis: Assign numeric "costs" to each field based on computational complexity. Calculate the total cost before executing queries and reject them if they exceed a predefined threshold.</li> Timeouts: Set enforced timeouts on query execution to prevent long-running queries from indefinitely occupying server resources.</li> Amount Limiting (Pagination): Always limit the number of records that can be returned from a list. Never allow clients to request unlimited items.</li> </ul> </li> </ul> Authorization Flaws</h2> Problem: GraphQL resolvers fetch data for specific fields. If permission checks aren't performed at the resolver level for each object, attackers may access data they shouldn't have permission to see. This is a classic Insecure Direct Object Reference (IDOR) vulnerability path.</li> Mitigation: Implement permission checks within each relevant resolver or as middleware layers. For every piece of data requested, the application should verify that the currently authenticated user has permission to view or modify that data. It's not sufficient to check authentication only at the endpoint level.</li> </ul> const resolvers = { Query: { user: (parent, { id }, context) => { // Permission check: Does the logged-in user have rights to view this profile? if (context.user.id !== id && !context.user.isAdmin) { throw new Error('You do not have permission to view this user'); } return db.users.find({ id: id }); } } }; </code></pre> Insufficient Error Handling</h2> Problem: Detailed error messages such as stack traces or database errors can leak sensitive information about your backend infrastructure, libraries used, and database schema.</li> Mitigation: Implement global error handlers that catch all exceptions. Log detailed errors for internal debugging purposes but return sanitized, generic error messages to clients. Libraries like graphql-errors</code> can help formalize this process.</li> </ul> Authentication</h2> Problem: GraphQL is transport-layer independent and doesn't enforce any particular authentication mechanism. It's up to developers to implement this correctly.</li> Mitigation: Treat GraphQL endpoints like any other sensitive API endpoint. Implement standard authentication mechanisms such as OAuth 2.0 or JWTs. Tokens should be passed via the Authorization</code> HTTP header and validated in a middleware layer before queries are processed. The validated user information should be stored in the GraphQL context</code> object for resolvers to use.</li> </ul> Conclusion</h2> Securing GraphQL APIs requires a shift in thinking from traditional endpoint-based security models. The flexible nature of GraphQL means that security must be an integral part of the core application logic. By disabling introspection in production environments, implementing strong controls against resource exhaustion attacks, enforcing object-level authorization within resolvers, and carefully managing error responses, developers can build robust and secure GraphQL applications. Security is not a feature to add at the end, but a fundamental requirement to consider throughout the development lifecycle. Integrating Mermaid.js in Zola 2025-06-17T00:00:00+00:00 Mermaid.js</a> is a powerful library that lets you create various diagrams using Markdown-like syntax. In this post, I'll walk you through the steps to integrate Mermaid.js into a Zola static site generator and how to optimize its performance. quadrantChart title Reach and engagement of campaigns x-axis Low Reach --> High Reach y-axis Low Engagement --> High Engagement quadrant-1 We should expand quadrant-2 Need to promote quadrant-3 Re-evaluate quadrant-4 May be improved Campaign A: [0.3, 0.6] Campaign B: [0.45, 0.23] Campaign C: [0.57, 0.69] Campaign D: [0.78, 0.34] Campaign E: [0.40, 0.34] Campaign F: [0.35, 0.78] </code></pre> quadrantChart title Reach and engagement of campaigns x-axis Low Reach --> High Reach y-axis Low Engagement --> High Engagement quadrant-1 We should expand quadrant-2 Need to promote quadrant-3 Re-evaluate quadrant-4 May be improved Campaign A: [0.3, 0.6] Campaign B: [0.45, 0.23] Campaign C: [0.57, 0.69] Campaign D: [0.78, 0.34] Campaign E: [0.40, 0.34] Campaign F: [0.35, 0.78] </pre> </div> </div> 1. Creating a Shortcode</h2> The first step to using Mermaid.js in Zola is to create a shortcode. I created mermaid.html in the templates/shortcodes directory. <pre class="mermaid"> {{ body }} </pre> </code></pre> This shortcode is very simple; it just generates a <pre></code> tag with the mermaid class. However, Mermaid.js identifies this mermaid class to convert the content into a graph, making it incredibly easy to create diagrams. You can use it like this code in markdown. {% mermaid() %} sequenceDiagram Alice->>+John: Hello John, how are you? Alice->>+John: John, can you hear me? John-->>-Alice: Hi Alice, I can hear you! John-->>-Alice: I feel great! {% end %} </code></pre> 2. Adding the Mermaid.js Library</h2> CDN Approach (Initial Method)</h3> Initially, I used a CDN to load Mermaid.js. I added the code to load mermaid.js in my overall layout, base.html</code>:  <script type="module"> import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs'; mermaid.initialize({ startOnLoad: true, theme: 'dark' }); </script> </code></pre> This method was simple to implement but came with the downsides of external dependency and potential network latency. Internalizing with Local Files (Optimization)</h3> To improve performance and remove external dependencies, I internalized Mermaid.js by saving it as a local file. First, I found that .mjs files were difficult to handle as they often load multiple chunks. So, I opted to download the .js</code> file instead. curl -s https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.min.js -o static/js/mermaid.min.js </code></pre> Afterward, I loaded it in base.html by referencing the local path:  <script src="/js/mermaid.min.js"></script> <script> mermaid.initialize({ startOnLoad: false, theme: 'dark' }); </script> </code></pre> 3. Optimizing the Rendering Method</h2> startOnLoad Method (Initial Method)</h3> Initially, I used Mermaid.js's default rendering method, startOnLoad: true</code>. mermaid.initialize({ startOnLoad: true, theme: 'dark' }); </code></pre> While this method automatically rendered all diagrams upon page load, it caused a delay in rendering because it waited for all other elements, like images, to fully load on the page. Manual Rendering Method (Optimization)</h3> I realized it would be better to proceed immediately once the Mermaid code was fully loaded. So, I switched to manually specifying the rendering time. I set startOnLoad: false</code> to prevent automatic rendering and then changed it to manually render only the necessary elements after the DOM was loaded. mermaid.initialize({ startOnLoad: false, theme: 'dark' }); document.addEventListener('DOMContentLoaded', async () => { const mermaidElements = document.querySelectorAll('.mermaid'); if (mermaidElements.length > 0) { await mermaid.run({ nodes: mermaidElements }); } }); </code></pre> As a result, as soon as objects with the mermaid class are identified, rendering starts almost simultaneously with page access. Conclusion</h2> Let's test with a simple example to see if it works well mindmap root((mindmap)) Origins Long history ::icon(fa fa-book) Popularisation British popular psychology author Tony Buzan Research On effectiveness and features On Automatic creation Uses Creative techniques Strategic planning Argument mapping Tools Pen and paper Mermaid </pre> It works perfectly! The Art of Agentic Coding 2025-06-14T00:00:00+00:00 The coding paradigm is rapidly changing with AI. I've heard the term 'Vibe Coding' being thrown around, but honestly, I'm not quite sure what to make of it. The idea of generating code based on just a feeling or atmosphere doesn't sit right with me, as it seems to undermine the essence of the coding experience I value. However, Agentic Coding is a bit different. It goes beyond simply requesting code generation; it's about delegating specific tasks to an AI agent. It's much closer to having a pair programmer by my side. This approach has allowed me to write more code faster without losing my coding intuition or my grip on the project's direction. For me, Agentic Coding is closer to the ideal model of collaboration. In this post, I want to share the practices and experiences that have helped me get better at using Agentic Coding. Agentic Coding</h2> Agentic Coding isn't fundamentally different from writing code with existing AI-based IDEs. The key difference is that instead of just instructing an AI agent to write a specific piece of code, you give it a degree of autonomy and delegate entire tasks for it to solve. The core of this process is an iterative loop of generating, modifying, verifying, and testing code to complete the given task. --- title: Agentic Coding Workflow @hahwul --- graph LR A(Task) --> B[Planning]; B --> C[Code Generation]; C --> D[Verification & Testing]; D --> E[Request review]; E --> F{Solve?}; F -- No --> B; F -- Yes --> G(End); </pre> Keys to Effective Agentic Coding</h2> After working on several projects with AI agents, I've realized there are a few key things that make the collaboration more effective. While you can handle simple tasks without much setup, the results are vastly different when you have a well-configured environment. Here are some of the points I've noted. Know Your Project</h3> The most important thing is that the developer—you—must be the captain of the ship. The AI is a capable crew member, but making the final decisions and seeing the big picture is the captain's job. You need a clear understanding of the project's architecture, goals, and constraints to give the AI precise instructions and to properly evaluate and integrate its output. Parallel-Friendly Code Structure</h3> AI agents aren't like humans. When you consider using multiple agents simultaneously or having one agent handle several tasks in parallel, it's far more effective if the code is logically and clearly separated. This might conflict with some traditional programming concepts, but in AI collaboration, having clearly divided units of work has proven more efficient. I've personally found it much easier to delegate tasks in a structure where features are broken down into packages or libraries. graph TD A[Monolithic Application] --> B{Core Logic}; B --> C[Feature A Integration]; B --> D[Feature B Integration]; B --> E[Feature C Integration]; C --> F(UI Module); D --> G(Database Module); E --> H(API Module); subgraph "Tightly Coupled" B --- C; B --- D; B --- E; end </pre> Traditional Code Structure (Less Parallel-Friendly) graph TD A[Main Orchestrator Agent] --> B{Task Delegation}; B --> C[Agent Feature A Package]; B --> D[Agent Feature B Package]; B --> E[Agent Feature C Library]; C --> F(Sub-Task 1.1); C --> G(Sub-Task 1.2); D --> H(Sub-Task 2.1); E --> I(Sub-Task 3.1); E --> J(Sub-Task 3.2); subgraph "Loosely Coupled" C; D; E; end </pre> Parallel-Friendly Code Structure (Optimized for AI Agents) The Importance of Tooling</h3> AI makes mistakes. But well-established tooling can significantly reduce those mistakes and help correct them quickly when they do happen. Linters, formatters, and testers are no longer optional; they're essential. Verifying that the generated code has no issues. I've been reminded once again of the importance of TDD (Test-Driven Development). In projects with thorough test coverage, I've had many impressive experiences where the AI generated faulty code, discovered the issue during the CI/CD pipeline's test phase, and then corrected itself. An interesting side note, however, is that AI also uses various tricks to pass tests. If you look closely, you'll sometimes see it deleting test cases or finding shortcuts to get a pass. This is something that needs to be caught during the code review phase. Language Choice & Clear Errors</h3> I've often been asked, "If you're coding with AI, what language is best?" The language itself might not be the most critical factor. However, from my personal experience, languages that provide detailed and friendly error messages are more advantageous for AI collaboration. When the compiler or interpreter clearly states "what" went wrong and "why," the AI's chances of fixing the problem increase. For that reason, I chose Rust, and I've been quite satisfied with the results. Docs for AI (AI-README)</h3> We usually write a README.md</code> file for our projects. I take it a step further and create a separate document, like AGENTS.md</code> ,AI.md</code>, specifically for the AI agent to read. In this document, I outline the project's overall structure, the role of each module, a list of key files to reference, and the rules that must be followed during coding. The presence of this document has made a huge difference in the AI's ability to understand the project and perform its tasks. Clear, Granular Tasks</h3> The more abstract and larger the task, the more the AI struggles. Of course, the same could be said for humans. As I've used AI agents more, I've found myself breaking down tasks into much smaller and more clearly defined pieces than I used to. Instead of a large task like 'Implement login feature,' providing specific instructions like '1. Define user model, 2. Create database schema, 3. Implement password hashing logic...' yields much better results. Even if you have to assign a large task, it's best to provide a detailed plan for the AI to follow. In this respect, Jules, which I'll discuss in the workflow section below, has a distinct advantage. In Jules, a plan is created and first reviewed by the user before the task is executed. My Current Workflow</h2> Locally, I usually delegate tasks from the Agent Panel in Zed</a>, close the tab, and get on with my other work. It's convenient because it uses macOS notifications to let me know when it's done. In a cloud environment, I frequently use Google's Jules</a>. Jules has given me a great experience of being able to assign tasks continuously, regardless of my location or situation. I often find myself giving it instructions from my phone when I'm out. I'm also very interested in terminal-based tools like Codex and Claude Code. However, what I'm most excited about is the GitHub Copilot Coding Agent (the one previously introduced as Padawan)</a>. I manage most of my tasks as GitHub Issues, and this Agent is expected to understand and execute tasks based on those issues. This would streamline the process of organizing and delegating work significantly. While I could try some features now with the GitHub Pro Plus plan, I'm currently receiving the Pro plan for free from GitHub, which makes switching a bit awkward. For now, I plan to stick with my current environment and think it over slowly. Since Gemini CLI was released in June 2025, I have primarily been using Zed, Jules, and the Gemini CLI. I also use Gemini and Grok in parallel for research. Final Thoughts</h2> Of course, what I've shared today won't be a one-size-fits-all solution. I hope you'll take it as the personal experience and opinion of one developer coding with AI. I believe the change brought by AI is an unstoppable tide of our times. There's no need to be afraid of a changing era. We just need to ride the wave and go with the flow. What's clear is that the way we develop has changed significantly, and we too must change to some extent. But as always, the fundamentals are important. AI is a tool and a companion that you can leverage only as much as you know. To make better use of this new colleague, we must continue to train and grow ourselves. Ultimately, in the age of AI, your competitive edge as a developer will be determined by how well you can handle AI and how solid your own fundamental skills are. DevSecOps 2025-06-08T00:00:00+00:00 DevSecOps is a culture and practice that aims to integrate security into every phase of the software development lifecycle (SDLC). It emphasizes collaboration between Development, Security, and Operations teams. The goal is to build secure software from the ground up, reduce vulnerabilities, and ensure faster, safer deployments. This roadmap provides a curated list of resources and tools to help individuals and organizations implement DevSecOps practices. Github</a> Jwt-Hack: Reborn in Rust 2025-06-06T00:00:00+00:00 Back in October 2020, I created a tool called jwt-hack</a> to make security testing for JSON Web Tokens (JWTs) a bit more convenient. At the time, this Go-based tool was a project born out of my own necessity, focusing on its core crack</code> feature to find JWT signing secrets using wordlists or brute force. Truth be told, for the nearly five years since, the project has been somewhat neglected compared to my other work. While I made small improvements here and there, a part of me always felt it deserved more. That's why I finally decided to take the plunge and give the project a complete reboot, leading to the release of a new major version: jwt-hack v2. In this post, I'd like to briefly share what the key changes in jwt-hack v2 are and where the project is headed next. From Go to Rust: The Core Change</h2> The biggest change in v2 is the complete switch from Go to Rust. Rewriting all the existing Go code in Rust took a fair amount of effort, but I believe it was a worthwhile endeavor. The primary reason was stability. Frankly, v1 would occasionally run into unexpected memory-related issues. Thanks to Rust's Ownership system and its strict compile-time checks, I was able to prevent these kinds of bugs at the source, resulting in a much more stable tool. Of course, a performance boost came along as a bonus. Even a simple benchmark shows a pretty satisfying speed improvement. Metric</th> jwt-hack v1</code></th> jwt-hack v2</code></th></tr></thead> Time (mean ± σ)</td> 1.874 s ± 0.033 s</td> 678.6 ms ± 165.8 ms</td></tr> Range (min … max)</td> 1.834 s … 1.935 s</td> 623.5 ms … 1150.4 ms</td></tr> User Time</td> 7.312 s</td> 3516.7 ms</td></tr> System Time</td> 1.985 s</td> 491.1 ms</td></tr> Runs</td> 10</td> 10</td></tr> </tbody></table> Performance comparison of the crack</code> feature under identical conditions ($ jwt-hack crack eyJ0e... --mode brute --max 4</code>) Strengthening the Foundation</h2> This wasn't just about changing the language; I also focused on strengthening the project's foundation. Test Coverage</h3> One of the areas I paid the most attention to during v2's development was the test code. I wrote far more thorough tests compared to the previous version, creating a solid base to minimize side effects from future code changes and maintain stability as new features are added. Compatibility</h3> Even though it's a major version release, all the command-line options and usage patterns from v1 are fully inherited. This means you can update and apply it to your existing scripts or pipelines without any migration work. Expanded Features</h2> Building on the stability and development convenience gained from the switch to Rust, I've added several features that I'd long felt were necessary. Support for More Algorithms</h3> While it previously focused on HMAC-based algorithms (HS256, HS384, HS512), jwt-hack now supports asymmetric encryption algorithms like RSA (RS*) and ECDSA (ES*). New Key-Based Functionality</h3> Going beyond simple secret-based testing, it's now possible to generate, verify, and test tokens using private/public keys. For example, you can easily create a JWT signed with a private key like this: ssh-keygen -t rsa -b 4096 -E SHA256 -m PEM -P "" -f RS256.key jwt-hack encode '{"a":"z"}' --private-key RS256.key --algorithm=RS256 </code></pre> New Verify Mode</h3> Truth be told, the previous version lacked even the basic functionality to verify if a JWT's signature was valid. This update introduces a verify</code> mode that allows you to check a token's signature with a secret or a public key, making the tool more complete for token testing. Broader Attack Vector Support</h3> One of jwt-hack's core features is generating tokens for known attack vectors. In addition to the existing none</code> algorithm and jku/x5u</code> attacks, it now supports a wider range of vectors and will continue to expand in the future: Algorithm Confusion (tampering with the alg</code> header to HS256)</li> SQL Injection in kid</code> (inserting an SQLi payload into the kid</code> header)</li> Other known attack techniques</li> </ul> Installation</h2> Cargo</h3> If you're a Rust developer, you can install it directly via cargo</code>. cargo install jwt-hack </code></pre> Homebrew</h3> And for one of the most exciting pieces of news: jwt-hack is now included in the official homebrew-core</code>! You can install and update it with a simple command, no need to tap a separate repository. brew install jwt-hack </code></pre> More</h3> You can also get jwt-hack through various other channels, including the Snapcraft Package</a>, Docker Hub</a>, and GHCR</a>. Final Thoughts</h2> Breathing new life into a long-neglected project was more enjoyable than I expected. It was great to see the tool improve, but what made it particularly fun was the process of getting to know the Rust language more deeply. Going forward, I plan to build jwt-hack into a comprehensive tool packed with various features for JWT security testing. If you have any ideas for necessary features or improvements, please don't hesitate to leave a comment on the GitHub Issues</a>. Your interest is the driving force behind this project. JWT-HACK 2025-06-06T00:00:00+00:00 # Cargo cargo install jwt-hack # Brew brew tap hahwul/jwt-hack brew install jwt-hack </code></pre> JWT-HACK is a CLI tool for analyzing JSON Web Tokens (JWTs). It supports encode</code>, decode</code>, verify</code>, crack</code>, and payload</code> modes to help you analyze JWTs and discover security vulnerabilities. Github</a> • Crates</a> 2020.10</div> </div> Started as my personal project with golang</div> </li> 2025.06</div> </div> Released v2, migrated from Go to Rust</div> </li> </ul> Jekyll to Zola 2025-05-31T00:00:00+00:00 It's been nearly three years since I switched back from Hugo to Jekyll</a> in August 2022 (see that post here), and now I'm making another move – this time to a tool called Zola. I wanted to share this journey in a post. While Zola isn't as mainstream or as large a project as Hugo or Jekyll, it has its own unique charm. I'll briefly introduce Zola and explain why I decided to make the switch. What is Zola?</h2> Zola</a> is a Static Site Generator (SSG) built with Rust. It uses its own template engine, Tera, and much like Hugo, it's distributed as a single binary. This means it's incredibly fast and doesn't require installing a bunch of separate dependencies. Furthermore, it comes with many convenient built-in features like Sass/SCSS compilation, syntax highlighting, table of contents generation, shortcodes, and internationalization (i18n) support, all without needing extra plugins, which makes for excellent usability. Why Zola?</h2> Over the past few years, my development toolkit has increasingly filled up with Rust-based tools like Caido</a>, Helix</a>, Zed</a>. Starting this year, Rust has also become my primary programming language, and I've been diving deep into it. Naturally, this trend led me to explore other tools within the Rust ecosystem, and Zola was one of the appealing projects I discovered this way. This tool and its template engine tera were born from an intense dislike of the (insane) Golang template engine and therefore of Hugo that I was using before for 6+ sites. Vincent Prouillet</cite> </blockquote> One of the main reasons I switched back from Hugo to Jekyll in the past was the complexity and, frankly, the awkwardness of Go's template engine. It seems Vincent Prouillet, Zola's developer, felt similarly. This shared sentiment about development philosophy played a significant role in my decision to choose Zola. Of course, its technical appeal was a big factor too. After considering various factors, I decided to migrate to Zola, and I'm currently very satisfied with it. Especially compared to Jekyll, where build times could be a bit disappointing and its characteristic live reloading was often slow, Zola's live reloading is incredibly fast, which has significantly improved my writing experience. Additionally, the ability to handle internationalization (i18n) easily without complex configurations was another major factor in choosing Zola. Design</h2> Migrating to Zola, I kept the core design philosophy of my existing Jekyll theme but rewrote the code to make it cleaner and more polished overall. Zola's template engine, Tera, is conceptually similar to Jekyll's Liquid but also resembles Jinja2 or Django templates, offering a more intuitive syntax. This made migrating and improving the existing logic relatively straightforward. A key difference I noticed is that with Jekyll, frequent page referencing can significantly impact build times. Zola doesn't seem to suffer from this to the same extent, which allowed me to enhance template reusability with macros without a noticeable performance penalty. Thanks to this, I managed to shorten the migration period considerably, more so than I initially anticipated. Visually, I stuck with the existing black-based (#000000</code>) theme but made the white accent points a bit more eye-catching. Good examples are the interactive elements on the main page and the 404 page. https://www.instagram.com/p/DJUO-64xTSC/</a> This sort of feel and the way it's expressed is something I came up with after getting inspired by a scene from the drama Loki season 2. Loki season 2's ending scene Conclusion</h2> Changing the underlying tool of a blog can sometimes be arduous and lead to unexpected challenges, but it has always given me the opportunity to learn new technologies and create better outcomes. This migration to Zola was no different. Of course, who knows, a few years down the line, another whim might lead me to seek out a new tool. But for now, I'm extremely satisfied with Zola's simplicity, speed, and the sense of stability and development philosophy that comes from it being Rust-based. Looking ahead, I plan to continue cultivating my blog while also contributing, even in small ways, to the Zola project, hoping to help this wonderful tool continue to evolve. How to Secure Cookies 2025-05-28T00:00:00+00:00 Cookies play a crucial role in web applications, but at the same time, they require careful attention to security settings. In this post, we'll take an in-depth look at various attributes to manage cookies more securely. We'll particularly explore how attributes like SameSite</code>, along with HttpOnly</code>, Secure</code>, Path</code>, Domain</code>, Expires</code>, and Max-Age</code>, each contribute to bolstering cookie security. The Importance of Cookie Security</h2> Cookies can store sensitive information, such as session IDs that identify users. If these cookies are stolen by an attacker, there's a risk of session hijacking, allowing unauthorized access to user accounts. Furthermore, cookies can be exploited in Cross-Site Request Forgery (CSRF) attacks, leading users to perform unintended actions on a website. Therefore, it's critically important to understand each cookie attribute and configure them correctly. Key Cookie Attributes for Enhanced Security</h2> Let's delve into the core security attributes that will help make your cookies robust. HttpOnly: Protecting Against XSS</h3> When the HttpOnly</code> attribute is set, the cookie cannot be accessed via JavaScript's document.cookie</code> API. This is effective in preventing attackers from stealing user cookie values (especially session IDs) through malicious scripts injected via Cross-Site Scripting (XSS) vulnerabilities on a website. Example (HTTP Header): Set-Cookie: session_id=verysecretvalue; HttpOnly </code></pre> It's advisable to set the HttpOnly</code> attribute for sensitive cookies, particularly those related to user authentication. While it's a fundamental defense mechanism, its effectiveness is significant. Secure: Ensuring Encrypted Transmission</h3> A cookie with the Secure</code> attribute is only transmitted over an HTTPS connection. This means the cookie won't be sent over unencrypted HTTP connections, thereby protecting it from Man-in-the-Middle (MITM) attacks where an attacker might intercept the cookie on the network. Example (HTTP Header): Set-Cookie: user_preference=dark_mode; Secure </code></pre> As most modern websites use HTTPS by default, applying the Secure</code> attribute is also recommended. It's especially crucial to remember that if you use the SameSite=None</code> policy, the Secure</code> attribute must be set concomitantly. SameSite: The CSRF Shield (In-Depth)</h3> The SameSite</code> attribute plays a pivotal role in defending against Cross-Site Request Forgery (CSRF) attacks. This attribute instructs the browser whether a cookie should be sent with requests initiated from other origins (cross-site). In simpler terms, it controls whether a cookie from your website (siteA.com</code>) will be included in a request sent from an unrelated website (evil.com</code>) to siteA.com</code>. The SameSite</code> attribute can have one of three values: Strict</code>: This provides the strongest level of protection. Cookies set with SameSite=Strict</code> are only sent if the request originates from the same site (a first-party context) where the user is currently interacting. For example, if a user clicks a link from an external site to yours, cookies set to Strict</code> will not be sent. Consequently, if a login session cookie is set to Strict</code>, the user might appear logged out when arriving via an external link and may need to log in again. When to use: Suitable for cookies related to actions that change state, such as password changes, content creation, or order processing.</li> Example: Set-Cookie: session_id=verysecretvalue; SameSite=Strict</code></li> </ul> </li> Lax</code>: This is a slightly more relaxed setting than Strict</code> but still offers excellent security. Lax</code> generally behaves like Strict</code> and doesn't send cookies on most cross-site requests. However, it does send cookies on cross-site requests if it's a top-level navigation using a safe HTTP method (GET, HEAD, OPTIONS, TRACE), such as when a user clicks a link to navigate to your site from an external one. This allows users to maintain their logged-in state when arriving from external links without compromising on CSRF protection for most scenarios. Many modern browsers have adopted Lax</code> as the default for cookies where no SameSite</code> attribute is specified. When to use: Well-suited for general session management cookies, offering a good balance between security and user experience.</li> Example: Set-Cookie: tracking_id=randomstring; SameSite=Lax</code></li> </ul> </li> None</code>: With this setting, cookies are sent on all requests, both same-site and cross-site, similar to how cookies behaved before the SameSite</code> attribute was introduced. However, a critical requirement is that if SameSite=None</code> is used, the Secure</code> attribute must also be specified (SameSite=None; Secure</code>). This enforces that the cookie only operates over HTTPS connections, a measure to mitigate security risks. When to use: Used sparingly, for cases where cookies are explicitly needed in a cross-site context, such as when your service is embedded within an iframe on an external service and requires cookie-based authentication, for Single Sign-On (SSO) scenarios spanning multiple domains, or for ad and analytics scripts.</li> Important: As this is the most flexible option, it also carries potential risks. Use it cautiously and only when absolutely necessary, and never omit the Secure</code> attribute.</li> Example: Set-Cookie: third_party_widget_session=externalvalue; SameSite=None; Secure</code></li> </ul> </li> </ul> Which SameSite</code> value should you choose? If there's no specific reason otherwise, using SameSite=Lax</code> as a default is a good practice. For cookies handling highly sensitive operations, SameSite=Strict</code> can be considered. If cookies are absolutely required for cross-site requests, then SameSite=None; Secure</code> is the appropriate approach. Path: Defining Cookie Scope by URL Path</h3> The Path</code> attribute restricts the URL path on the server to which the cookie will be sent. For instance, a cookie set with Path=/admin</code> will only be sent for requests to /admin</code> and its subdirectories (e.g., /admin/users</code>). It will not be sent for requests to other paths like /dashboard</code> or the root (/</code>). Example (HTTP Header): Set-Cookie: admin_session_token=secretadminstuff; Path=/admin; HttpOnly; Secure </code></pre> This helps minimize the cookie's exposure by preventing it from being unnecessarily transmitted to other application contexts. If not specified, the default path is the path of the document that set the cookie. Domain: Defining Cookie Scope by Host</h3> The Domain</code> attribute specifies the host(s) to which the cookie will be sent. If set to Domain=example.com</code>, the cookie will be sent for requests to example.com</code> and all its subdomains (e.g., www.example.com</code>, api.example.com</code>). If the Domain</code> attribute is omitted, the cookie is sent only to the exact host that set it (excluding subdomains). Example (HTTP Header): Set-Cookie: site_wide_preference=blue_theme; Domain=example.com </code></pre> Overly broad Domain</code> settings (e.g., to a TLD like .com</code>) are a security risk and are rejected by browsers. Also, the Domain</code> attribute can only be set to the current host's parent domain; it cannot be set to a completely different domain. Expires & Max-Age: Managing Cookie Lifetime</h3> It's important to manage cookie persistence by setting an expiration time. Two attributes are used for this: Expires</code> and Max-Age</code>. Expires</code>: Specifies the exact date and time (in UTC) when the cookie will expire. Example: Set-Cookie: legacy_cookie=data; Expires=Fri, 31 Dec 2025 23:59:59 GMT</code></li> </ul> </li> Max-Age</code>: Specifies the duration, in seconds, until the cookie expires. For example, Max-Age=3600</code> means the cookie is valid for one hour. Max-Age</code> takes precedence over Expires</code>. If Max-Age</code> is set to 0 or a negative value, the cookie is deleted immediately. Example: Set-Cookie: short_lived_token=tempdata; Max-Age=3600</code></li> </ul> </li> </ul> If neither Expires</code> nor Max-Age</code> is set, the cookie is treated as a session cookie and is deleted when the browser is closed. However, as browser settings might restore sessions (and thus session cookies), it's a safer practice to set an explicit, short expiration time for sensitive information. Advanced Cookie Theft Detection and Mitigation</h2> Even with all the security attributes correctly configured, there remains a risk of cookie theft through malware or phishing attacks. Therefore, implementing detection mechanisms for identifying potentially stolen cookies is crucial for comprehensive security. Environment-Based Detection</h3> By storing user environment information when a session is established, you can detect suspicious changes that might indicate session hijacking: IP Address Change: Significant changes in IP address or geo-location might indicate session hijacking. For instance, if a user who typically logs in from New York suddenly appears to be accessing your site from a different country.</li> User-Agent Change: Different browsers or devices sending requests with the same cookie.</li> Language Preference Change: Sudden changes in the Accept-Language</code> header.</li> Access Time Patterns: Activity during unusual hours for a particular user.</li> </ul> Example Implementation (Server-side): // When creating a session session.save({ ip: request.clientIP, userAgent: request.headers.userAgent, language: request.headers.acceptLanguage, // Additional environment information }); // On subsequent requests if (hasSignificantEnvironmentChange(session, request)) { // Take action - trigger additional verification } </code></pre> Risk-Based Session Validation</h3> When suspicious activity is detected, implement graduated response mechanisms: Low Risk: Display a CAPTCHA to verify human interaction</li> Medium Risk: Request additional verification (security question, email verification code)</li> High Risk: Force re-authentication with full credentials and potentially 2FA</li> Critical Risk: Immediately invalidate the session and notify the user via alternate channels</li> </ul> It's important to balance security with user experience—too many verification requests can frustrate legitimate users. Consider implementing risk-based verification only for sensitive operations like payment processing, account settings changes, or password updates. Device-Bound Session Credentials</h3> A promising approach to mitigating cookie theft is using device-bound session credentials. This technique binds session cookies to the specific device through cryptographic means: The browser generates a public-private key pair during login</li> The session is cryptographically tied to this key pair</li> Even if the cookie is stolen, the attacker cannot use it without the private key stored securely on the original device</li> </ul> While this technology is still evolving and not yet widely supported, it represents the future direction for secure session management as it changes cookies from simple bearer tokens to sender-constrained tokens. Conclusion: Layered Security is Key</h2> We've explored various attributes for cookie security in detail: HttpOnly</code>, Secure</code>, SameSite</code>, Path</code>, Domain</code>, Expires</code>, and Max-Age</code>, as well as advanced techniques for detecting and mitigating cookie theft. Understanding how each security measure works and its benefits is crucial. The core of cookie security lies in using these protections appropriately in combination. No single setting can defend against all threats, so always consider a defense-in-depth strategy to protect your web applications and users. In addition to configuring cookie attributes correctly, implementing server-side detection mechanisms provides an essential additional layer of security.

HAHWUL

Hello SmuggleX 👋🏼

Red, Blue, Purple in Offensive Security

Beginner’s Guide: Creating Your First Ruby Project

Beginner’s Guide: Creating Your First Rust Project

Beginner’s Guide: Creating Your First Crystal Project

How to Hack Web Assembly

Structure</h3>

WebAssembly Overview</h4> WebAssembly is a low-level assembly language that can process binary formats on the web. It works together with JavaScript and has the following characteristics:</p>

Hack Mechanism</h2> WebAssembly operates the same way in each browser, creating an environment where both traditional binary attacks and web hacking techniques can be applied.</p>

Security Testing Points</h3> WebAssembly applications have the following security testing points:</p>

Code audit</h3> WebAssembly files typically have a .wasm</code> extension and are provided in binary format. For analysis, you need to decompile them and examine the related JavaScript code together.</p>

Find WASM files</h4> Methods to find WebAssembly files:</p> Finding WebAssembly instances in JavaScript</strong>: Like SWF and ActiveX, since they're ultimately handled in JS, function or address information remains in the code.</p> </li>

Live audit</h3>

Function testing</h4> You can directly call WASM functions from JavaScript for testing. This is identical to SWF or ActiveX analysis methods.</p> </p>

A major weakness</h3>

🛠 Environment</h2>

Articles</h2> How to analyze security vulnerabilities in WebAssembly?</a></li> </ul> References</h2> WebAssembly Security</a></li> BlackHat WebAssembly Paper</a></li> MDN WebAssembly</a></li> WebAssembly Binary Toolkit</a></li> </ul>

OWASP Seoul Meetup

Search in Zola: Fuse.js vs. Elasticlunr.js

How to Integrate with Zola?</h2> Zola allows easy configuration of search UI with Tera templates and JavaScript. Depending on the config.toml</code> settings, a JSON format index file is generated during build, which can be loaded in JavaScript to add search functionality.</p>

Goyo

Dalfox 2.12 Released ⚡︎

Improve help message (grouping)</h2> The readability of the --help</code> message has been improved. Options are now grouped by function, making it much cleaner and easier to read.</p> </p>

New payload patterns</h2> Recently shared payloads have been added, such as those for codebase-based XSS.</p>

Add markdown report format</h2> A markdown</code> (or md</code>) format has been added to the --report-format</code> option. You can now save scan results as a clean markdown report, making it easy to integrate into other documents.</p>

API Key based authentication</h3> The --api-key</code> flag has been added to Server mode. By setting an API Key with this flag, you can operate the scanner more securely by only allowing requests that include the key in the X-API-Key</code> header.</p>

CORS, JSONP support</h3> Server mode now supports Cross-Origin Resource Sharing (CORS) and JSONP. The --allow-origins</code> and --jsonp</code> flags allow for more flexible integration of the Dalfox API with web applications from other domains.</p>

Pipe mode</h2> Here are the improvements for Pipe mode.</p>

Add raw HTTP request support to pipe mode</h3> Pipe mode now supports Raw HTTP Request as a direct input, just like File mode. This significantly improves interoperability, as you can directly pipe requests copied from proxy tools like Burp, Caido, and ZAP for testing.</p>

Documentation</h2> The documentation has been improved in line with the updates. @fabaff</a>, who maintains dalfox in Nixpkgs, also contributed to the documentation updates. I'd like to thank him again.</p>

Understanding DevSecOps

Understanding Content Security Policy (CSP)

How to Securing GraphQL

Integrating Mermaid.js in Zola

2. Adding the Mermaid.js Library</h2>

3. Optimizing the Rendering Method</h2>

The Art of Agentic Coding

DevSecOps

Jwt-Hack: Reborn in Rust

Compatibility</h3> Even though it's a major version release, all the command-line options and usage patterns from v1 are fully inherited. This means you can update and apply it to your existing scripts or pipelines without any migration work.</p>

Hack Mechanism</h2>
WebAssembly operates the same way in each browser, creating an environment where both traditional binary attacks and web hacking techniques can be applied.</p>

Code audit</h3>
WebAssembly files typically have a `.wasm</code> extension and are provided in binary format. For analysis, you need to decompile them and examine the related JavaScript code together.</p>`

Function testing</h4>
You can directly call WASM functions from JavaScript for testing. This is identical to SWF or ActiveX analysis methods.</p>
</p>

Articles</h2>

How to analyze security vulnerabilities in WebAssembly?</a></li> </ul>
References</h2>

WebAssembly Security</a></li>
BlackHat WebAssembly Paper</a></li>
MDN WebAssembly</a></li>
WebAssembly Binary Toolkit</a></li> </ul>

How to Integrate with Zola?</h2>
Zola allows easy configuration of search UI with Tera templates and JavaScript. Depending on the `config.toml</code> settings, a JSON format index file is generated during build, which can be loaded in JavaScript to add search functionality.</p>`

Improve help message (grouping)</h2>
The readability of the `--help</code> message has been improved. Options are now grouped by function, making it much cleaner and easier to read.</p>`
`</p>`

Pipe mode</h2>
Here are the improvements for Pipe mode.</p>

Documentation</h2>
The documentation has been improved in line with the updates. @fabaff</a>, who maintains dalfox in Nixpkgs, also contributed to the documentation updates. I'd like to thank him again.</p>

Compatibility</h3>
Even though it's a major version release, all the command-line options and usage patterns from v1 are fully inherited. This means you can update and apply it to your existing scripts or pipelines without any migration work.</p>