<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Diogo on ZAP</title>
    <link>/authors/diogo/</link>
    <description>Recent content in Diogo on ZAP</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 09 Mar 2020 00:00:00 +0000</lastBuildDate>
    <atom:link href="/authors/diogo/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>ZAP SSRF Setup</title>
      <link>/blog/2020-03-09-zap-ssrf-setup/</link>
      <pubDate>Mon, 09 Mar 2020 00:00:00 +0000</pubDate>
      <guid>/blog/2020-03-09-zap-ssrf-setup/</guid>
      <description>&lt;p&gt;Some vulnerabilities can only be found by sending payloads that cause a callback to the tester. One example is &lt;a href=&#34;https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing&#34;&gt;XXE vulnerabilities&lt;/a&gt; when the XML rendering result is not available to the user. ZAP can find these vulnerabilities that depend on &lt;a href=&#34;https://owasp.org/www-community/attacks/Server_Side_Request_Forgery&#34;&gt;SSRF&lt;/a&gt; detection but the target system needs to be able to reach the ZAP callback endpoint. In many cases the computer running ZAP is behind some kind of NAT and doesn’t have a public IP so it will not receive the expected callbacks and miss some of the existent vulnerabilities.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
