<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>SSRF on guy@secdev.uk</title>
    <link>https://www.secdev.uk/blog/tags/ssrf/</link>
    <description>Recent content in SSRF on guy@secdev.uk</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <copyright>Guy Dixon | guy@secdev.uk</copyright>
    <lastBuildDate>Sat, 27 Sep 2025 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.secdev.uk/blog/tags/ssrf/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Go Security: Goroutines, Error Handling, and Hidden Bugs</title>
      <link>https://www.secdev.uk/blog/technology/2025-09-27-go-security-goroutines-errors/</link>
      <pubDate>Sat, 27 Sep 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2025-09-27-go-security-goroutines-errors/</guid>
      <description>&lt;p&gt;Go&amp;rsquo;s simplicity is its greatest strength and, I&amp;rsquo;d argue, its most dangerous security property. The language has no exceptions, no generics-based abstractions (until recently), and no implicit behaviour, everything is explicit. But that explicitness creates its own class of vulnerabilities: unchecked errors that silently skip security validation, goroutine races on shared state, HTTP client defaults that follow redirects into internal networks, and string handling patterns that bypass input validation. In this post, I want to walk through the Go-specific anti-patterns that lead to security vulnerabilities, from the error that nobody checked to the goroutine that corrupted the authentication cache. The more I dug into Go&amp;rsquo;s security landscape, the more I realised these bugs are subtle precisely because the language feels so straightforward.&lt;/p&gt;</description>
    </item>
    <item>
      <title>SSRF</title>
      <link>https://www.secdev.uk/blog/technology/2025-06-07-ssrf/</link>
      <pubDate>Sat, 07 Jun 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2025-06-07-ssrf/</guid>
      <description>&lt;p&gt;Server-Side Request Forgery is one of those vulnerability classes that I&amp;rsquo;ve grown to respect more and more the deeper I dig into it. The idea is simple, you trick a server into making HTTP requests to destinations you choose, turning it into your personal proxy. It can reach internal services, cloud metadata endpoints, and private networks that you&amp;rsquo;d never touch directly from the outside. OWASP gave SSRF its own category (A10) in 2021, and reading through the rationale, it was overdue. The case studies are striking, a single SSRF against &lt;code&gt;http://169.254.169.254/&lt;/code&gt; on AWS can leak IAM credentials and compromise an entire account. In this post, I&amp;rsquo;ll walk through Python, Java, Go, and JavaScript examples, from the textbook URL-in-a-parameter to the subtle redirect-chain and DNS rebinding variants that make SSRF so hard to defend against.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
