<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Bug Class Deep Dives on Crusader Research</title>
		<link>https://crusaderproxy.com/research/en/series/bug-class-deep-dives/</link>
		<description>Recent content in Bug Class Deep Dives on Crusader Research</description>
		<generator>Hugo</generator>
		<language>en-US</language>
		
		
		
		
			<lastBuildDate>Sun, 05 Jul 2026 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://crusaderproxy.com/research/en/series/bug-class-deep-dives/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>SSRF past the easy filters: URL-parser confusion and the metadata endpoint</title>
				<link>https://crusaderproxy.com/research/en/posts/ssrf-past-the-easy-filters/</link>
				<pubDate>Sun, 05 Jul 2026 00:00:00 +0000</pubDate>
				<guid>https://crusaderproxy.com/research/en/posts/ssrf-past-the-easy-filters/</guid>
				<description>&lt;p&gt;Server-side request forgery is one of the few bug classes where a single finding hands you cloud credentials. The mechanic is trivial to state — you make a server fetch a URL you control — and every write-up stops there, which is exactly why they&amp;rsquo;re useless. The tutorial payload, &lt;code&gt;http://169.254.169.254/&lt;/code&gt; pasted into a URL field, has been blocklisted everywhere. The reason SSRF is still one of the most productive bug classes in 2026 isn&amp;rsquo;t that developers forgot to filter. It&amp;rsquo;s that &lt;strong&gt;their filter and their HTTP client read the URL differently, and you live in the gap.&lt;/strong&gt;&lt;/p&gt;</description>
			</item>
			<item>
				<title>Winning web race conditions with the single-packet attack</title>
				<link>https://crusaderproxy.com/research/en/posts/winning-the-race-condition-bugs/</link>
				<pubDate>Sun, 05 Jul 2026 00:00:00 +0000</pubDate>
				<guid>https://crusaderproxy.com/research/en/posts/winning-the-race-condition-bugs/</guid>
				<description>&lt;p&gt;Most write-ups tell you a race condition is a &amp;ldquo;timing window between check and use.&amp;rdquo; True, and useless — because the reason your race attacks fail isn&amp;rsquo;t that you don&amp;rsquo;t understand the concept. It&amp;rsquo;s that &lt;strong&gt;the window is smaller than the internet is precise.&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;A typical race window — the gap between an app reading &lt;code&gt;balance&lt;/code&gt; and writing &lt;code&gt;balance - amount&lt;/code&gt; — is measured in &lt;strong&gt;microseconds to a few milliseconds&lt;/strong&gt;. The jitter between two HTTP requests you &lt;em&gt;send&lt;/em&gt; at the same instant, by the time they &lt;em&gt;arrive&lt;/em&gt; and get scheduled on the server, is routinely &lt;strong&gt;1 to 10 milliseconds&lt;/strong&gt;, and worse across the public internet. So your &amp;ldquo;simultaneous&amp;rdquo; requests arrive in a neat little line, the server processes them one at a time, the limit holds, and you conclude the endpoint is safe. It isn&amp;rsquo;t. You just lost the race to network jitter before the server ever got a vote.&lt;/p&gt;</description>
			</item>
			<item>
				<title>IDOR lives in the second identifier: finding BOLA with two-account Shadow Replay</title>
				<link>https://crusaderproxy.com/research/en/posts/finding-idor-bola-with-shadow-replay/</link>
				<pubDate>Sat, 04 Jul 2026 00:00:00 +0000</pubDate>
				<guid>https://crusaderproxy.com/research/en/posts/finding-idor-bola-with-shadow-replay/</guid>
				<description>&lt;p&gt;Every IDOR tutorial hands you the same drill: find &lt;code&gt;/api/orders/48210&lt;/code&gt;, change it to &lt;code&gt;48211&lt;/code&gt;, look for a &lt;code&gt;200&lt;/code&gt;. That drill trains you to attack the one identifier the application is most likely to check. The primary key in the URL path is where the framework&amp;rsquo;s &lt;code&gt;@authorize&lt;/code&gt; annotation lives, where the ORM scopes the query, where the review focused. It&amp;rsquo;s the honeypot. You fuzz it, get &lt;code&gt;403&lt;/code&gt;s, call the endpoint safe, and walk right past the bug.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
