<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Cloud on Crusader Research</title>
		<link>https://crusaderproxy.com/research/hi/tags/cloud/</link>
		<description>Recent content in Cloud on Crusader Research</description>
		<generator>Hugo</generator>
		<language>hi</language>
		
		
		
		
			<lastBuildDate>Sun, 05 Jul 2026 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://crusaderproxy.com/research/hi/tags/cloud/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>आसान फ़िल्टरों को पार करते हुए SSRF: URL-parser की उलझन और metadata endpoint</title>
				<link>https://crusaderproxy.com/research/hi/posts/ssrf-past-the-easy-filters/</link>
				<pubDate>Sun, 05 Jul 2026 00:00:00 +0000</pubDate>
				<guid>https://crusaderproxy.com/research/hi/posts/ssrf-past-the-easy-filters/</guid>
				<description>&lt;p&gt;Server-side request forgery उन कुछ bug classes में से एक है जहाँ एक अकेली खोज आपके हाथ में cloud credentials थमा देती है। इसका तंत्र कहने में मामूली है — आप server से एक ऐसा URL fetch करवाते हैं जो आपके नियंत्रण में है — और हर write-up वहीं रुक जाता है, ठीक इसीलिए वे बेकार हैं। tutorial वाला payload, URL field में चिपकाया गया &lt;code&gt;http://169.254.169.254/&lt;/code&gt;, हर जगह blocklist हो चुका है। SSRF के 2026 में भी सबसे उपजाऊ bug classes में से एक बने रहने की वजह यह नहीं है कि developers filter करना भूल गए। वजह यह है कि &lt;strong&gt;उनका filter और उनका HTTP client URL को अलग-अलग पढ़ते हैं, और आप उसी अंतर में रहते हैं।&lt;/strong&gt;&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
