<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" 
  xmlns:content="http://purl.org/rss/1.0/modules/content/" 
  xmlns:dc="http://purl.org/dc/elements/1.1/" 
  xmlns:atom="http://www.w3.org/2005/Atom" 
  xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" 
  xmlns:media="http://search.yahoo.com/mrss/">
  <channel>
    <title>web on Sam&#39;s Hacking Wonderland</title>
    <link>https://netsec.expert/categories/web/</link>
    <description>Recent content in web on Sam&#39;s Hacking Wonderland</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <managingEditor>the@netsec.expert (Sam Anttila)</managingEditor>
    <webMaster>the@netsec.expert (Sam Anttila)</webMaster>
    <copyright>&amp;copy;{year}</copyright>
    <lastBuildDate>Thu, 04 Nov 2021 20:17:00 +0100</lastBuildDate>
    <sy:updatePeriod>weekly</sy:updatePeriod>
    
        <atom:link href="https://netsec.expert/categories/web/index.xml" rel="self" type="application/rss+xml" />
    

      
      <item>
        <title>Automating DOM XSS Discovery</title>
        <link>https://netsec.expert/posts/automating-dom-xss/</link>
        <pubDate>Thu, 04 Nov 2021 20:17:00 +0100</pubDate>
        <author>the@netsec.expert (Sam Anttila)</author>
        <atom:modified>Thu, 04 Nov 2021 20:17:00 +0100</atom:modified>
        <guid>https://netsec.expert/posts/automating-dom-xss/</guid>
        <description>This article is a brief introduction to static analysis tools to hunt for client-side web vulnerabilities while giving some examples of ways I&amp;rsquo;ve successfully employed it so you can have fun with these tools too.
What&amp;rsquo;s this about static analysis anyway? Static analysis is different from dynamic analysis (e.g., black-box testing with Burp). It never actually runs any code or depends on any running processes but instead parses raw source code.</description>
        
        <dc:creator>Sam Anttila</dc:creator>
        
        
        
        
        
          
            
              <category>bug hunting</category>
            
          
            
              <category>web</category>
            
          
            
              <category>development</category>
            
          
            
              <category>vulnerabilities</category>
            
          
        
        
      </item>
      
      <item>
        <title>Mitigation schmitigation: Control HttpOnly cookies through XSS</title>
        <link>https://netsec.expert/posts/mitigation-schmitigation-xss-and-httponly/</link>
        <pubDate>Mon, 16 Aug 2021 20:02:11 +0100</pubDate>
        <author>the@netsec.expert (Sam Anttila)</author>
        <atom:modified>Mon, 16 Aug 2021 20:02:11 +0100</atom:modified>
        <guid>https://netsec.expert/posts/mitigation-schmitigation-xss-and-httponly/</guid>
        <description>Did you know the &amp;lsquo;HttpOnly&amp;rsquo; cookie attribute, intended to make it so that JavaScript can not read or write a particular cookie, is more of a handwavy suggestion than a requirement?
It&amp;rsquo;s true.
In the modern version of Chrome, regardless of the underlying OS, you can overwrite cookies with HttpOnly set.
If you&amp;rsquo;ve been around long enough in web security or perhaps dug deep into the literature on web attacks, you might know this as &amp;lsquo;cookie jar overflow&amp;rsquo;, &amp;lsquo;cookie overflow&amp;rsquo; (my favorite because it sounds delicious), or &amp;lsquo;cookie forcing&amp;rsquo;, because it&amp;rsquo;s really not a new attack.</description>
        
        <dc:creator>Sam Anttila</dc:creator>
        
        
        
        
        
          
            
              <category>bug hunting</category>
            
          
            
              <category>vulnerabilities</category>
            
          
            
              <category>web</category>
            
          
        
        
      </item>
      

    
  </channel>
</rss>