<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Web Application Security on soffensive blog</title><link>https://soffensive.github.io/tags/web-application-security/</link><description>Recent content in Web Application Security on soffensive blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 18 May 2019 05:35:00 -0700</lastBuildDate><atom:link href="https://soffensive.github.io/tags/web-application-security/index.xml" rel="self" type="application/rss+xml"/><item><title>XXE with .NET in 2019</title><link>https://soffensive.github.io/posts/web-app-sec/2019-05-18-xxe-with-net-in-2019/</link><pubDate>Sat, 18 May 2019 05:35:00 -0700</pubDate><guid>https://soffensive.github.io/posts/web-app-sec/2019-05-18-xxe-with-net-in-2019/</guid><description>&lt;p>After the seminal blog post by &lt;a href="https://www.jardinesoftware.net/2016/05/26/xxe-and-net/" target="_blank" rel="noopener noreffer ">James Jardine&lt;/a> in 2016 on XXE exploitation in .NET applications back in 2016, Microsoft seems to have implemented some additional changes regarding the default behavior of XML parsers.&lt;/p>
&lt;p>We work through the different XML methods provided and their corresponding vulnerable configurations. For all experiments, .NET framework 4.6 was chosen.&lt;/p>
&lt;div class="details admonition tip open">
 &lt;div class="details-summary admonition-title">
 &lt;i class="icon fas fa-lightbulb fa-fw" aria-hidden="true">&lt;/i>TL;DR&lt;i class="details-icon fas fa-angle-right fa-fw" aria-hidden="true">&lt;/i>
 &lt;/div>
 &lt;div class="details-content">
 &lt;div class="admonition-content">&lt;p>In order to create an XXE vulnerability for applications using .NET framework 4.6+, you have to instantiate a vulnerable &lt;code>XmlResolver&lt;/code> beforehand.&lt;/p></description></item><item><title>Exploiting Blind File Reads / Path Traversal Vulnerabilities on Microsoft Windows Operating Systems</title><link>https://soffensive.github.io/posts/web-app-sec/2018-06-19-exploiting-blind-file-reads-path-traversal-vulnerabilities-on-microsoft-windows-operating-systems/</link><pubDate>Tue, 19 Jun 2018 01:31:00 -0700</pubDate><guid>https://soffensive.github.io/posts/web-app-sec/2018-06-19-exploiting-blind-file-reads-path-traversal-vulnerabilities-on-microsoft-windows-operating-systems/</guid><description>&lt;p>In a recent engagement I was confronted with a blind path traversal vulnerability on a server running with the Microsoft Windows operating system. That is, it was not possible to display folder contents but the complete file name and path had to be guessed. Due to the lack of a comprehensive website I was forced to gather information from various different sources.&lt;/p>
&lt;p>In this blog post, I want to summarize my findings and focus on the exploitation of  this kind of vulnerability.&lt;/p></description></item><item><title>Cross-Site Scripting Attacks with adverse Conditions: Upper-Case XSS</title><link>https://soffensive.github.io/posts/web-app-sec/2017-04-05-cross-site-scripting-attacks-with-adverse-conditions-upper-case-xss/</link><pubDate>Wed, 05 Apr 2017 04:03:00 -0700</pubDate><guid>https://soffensive.github.io/posts/web-app-sec/2017-04-05-cross-site-scripting-attacks-with-adverse-conditions-upper-case-xss/</guid><description>&lt;p>Several times I have encountered web applications that convert
user-provided input to capital letters. For example, the application may
behave as follows:&lt;/p>
&lt;p>&lt;a href="../images/2017-04-05-cross-site-scripting-attacks-with-adverse-conditions-upper-case-xss-up1.png" rel="">&lt;img
 class="lazyload"
 src="https://soffensive.github.io/svg/loading.min.svg"
 data-src="../images/thumbnails/2017-04-05-cross-site-scripting-attacks-with-adverse-conditions-upper-case-xss-up1.png"
 data-srcset="../images/thumbnails/2017-04-05-cross-site-scripting-attacks-with-adverse-conditions-upper-case-xss-up1.png, ../images/thumbnails/2017-04-05-cross-site-scripting-attacks-with-adverse-conditions-upper-case-xss-up1.png 1.5x, ../images/thumbnails/2017-04-05-cross-site-scripting-attacks-with-adverse-conditions-upper-case-xss-up1.png 2x"
 data-sizes="auto"
 alt="../images/thumbnails/2017-04-05-cross-site-scripting-attacks-with-adverse-conditions-upper-case-xss-up1.png"
 title="../images/thumbnails/2017-04-05-cross-site-scripting-attacks-with-adverse-conditions-upper-case-xss-up1.png" />&lt;/a>&lt;/p>
&lt;p>The injected JavaScript code (after escaping from the quotes, of course) will not be executed in the browser. Why is this the case? Remember that the HTML tag names themselves, including &lt;code>&amp;lt;SCRIPT&amp;gt;&lt;/code> are not case-sensitive, whereas the contents inside them are in fact case-sensitive.&lt;/p></description></item></channel></rss>