<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>dead &amp;&amp; end</title>
    <link>https://d3adend.org/blog/</link>
    <description>Recent content on dead &amp;&amp; end</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 25 Feb 2025 11:16:16 +0100</lastBuildDate><atom:link href="https://d3adend.org/blog/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Multiple Vulnerabilities in TCPDF</title>
      <link>https://d3adend.org/blog/posts/tcpdf-multiple-vulnerabilities/</link>
      <pubDate>Tue, 25 Feb 2025 11:16:16 +0100</pubDate>
      
      <guid>https://d3adend.org/blog/posts/tcpdf-multiple-vulnerabilities/</guid>
      <description>Introduction I recently identified multiple vulnerabilities in TCPDF, which is a popular library used for PDF generation (this is a repost from the NCC Group research blog). These issues were addressed in version 6.8.0 of the library.
Web applications and web services often utilize PDF generation libraries when generating PDFs based on user input in order to generate invoice documents or report export documents. TCPDF supports programmatically creating PDFs or creating PDFs based on HTML content, but applications are often exploitable when an attacker can control the HTML used to generate the PDF files.</description>
    </item>
    
    <item>
      <title>An Example WAF XSS Bypass</title>
      <link>https://d3adend.org/blog/posts/example-waf-xss-bypass/</link>
      <pubDate>Tue, 25 Jun 2024 12:46:16 +0100</pubDate>
      
      <guid>https://d3adend.org/blog/posts/example-waf-xss-bypass/</guid>
      <description>While testing a Java-based web application, I came across a straightforward reflected cross-site scripting (XSS) vulnerability on the application&amp;rsquo;s login page, but the web application utilized a popular web application firewall (WAF), so it initially appeared that only HTML injection was feasible until I could identify a rule bypass.
By combining the following basic techniques together I was able to bypass the WAF&amp;rsquo;s XSS rules.
 Custom HTML tag. HTML attribute encoding.</description>
    </item>
    
    <item>
      <title>Exploring the Security of KaiOS Mobile Applications</title>
      <link>https://d3adend.org/blog/posts/exploring-the-security-of-kaios-mobile-applications/</link>
      <pubDate>Mon, 24 Aug 2020 14:47:27 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/exploring-the-security-of-kaios-mobile-applications/</guid>
      <description>After passing thru a number of hurdles, I put together a whitepaper documenting vulnerabilities that I found in the operating system and various security risks of the platform. The whitepaper was originally posted on the NCC Group research page (this is just another repost). There are a couple interesting bugs documented in the paper including details on how I chained together a HTML injection vulnerability, a CSP bypass, and an over permissioned application in order to gain root level access on one device.</description>
    </item>
    
    <item>
      <title>Multiple Vulnerabilities in Multiple Vulnerabilities in KaiOS Pre-installed Mobile Applications</title>
      <link>https://d3adend.org/blog/posts/multiple-vulnerabilities-in-kaios-preinstalled-mobile-applications/</link>
      <pubDate>Fri, 21 Aug 2020 21:31:16 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/multiple-vulnerabilities-in-kaios-preinstalled-mobile-applications/</guid>
      <description>I found multiple HTML injection vulnerabilities in several KaiOS mobile applications that are pre-installed on KaiOS mobile devices (this is just a repost of the original found on the NCC Group research page). While exploiting a HTML injection vulnerability in a Firefox OS, or KaiOS, application normally has limited impact besides the ability to manipulate the applicaiton&#39;s user interface, I also used a CSP bypass in order to gain remote JavaScript injection, which allowed for abusing privileged JavaScript APIs (remotely stealing files from the device was possible).</description>
    </item>
    
    <item>
      <title>Eversec Cloud Write-ups (Internal NCC Group CTF 2020)</title>
      <link>https://d3adend.org/blog/posts/eversec-cloud-write-ups/</link>
      <pubDate>Sat, 04 Apr 2020 22:17:01 +0500</pubDate>
      
      <guid>https://d3adend.org/blog/posts/eversec-cloud-write-ups/</guid>
      <description>NCC Group&amp;rsquo;s internal conference for 2020 contained another capture the flag that had plenty of interesting challenges. Mad props to Gabe, Dan, and Clayton for running another smooth CTF. Like the previous year the CTF consisted of a handful of servers that participants had to break into in order to acquire enumeration, foothold, and root flags (plus random cryptography and forensic flags). The rules were largely unchanged from last year, but one of the major changes was that the number of flags for each machine was unknown.</description>
    </item>
    
    <item>
      <title>Multiple Vulnerabilities in Alcatel Flip 2</title>
      <link>https://d3adend.org/blog/posts/multiple-vulnerabilities-in-alcatel-flip-2/</link>
      <pubDate>Fri, 22 Nov 2019 21:31:16 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/multiple-vulnerabilities-in-alcatel-flip-2/</guid>
      <description>I found a number of vulnerabilities in the Alcatel Flip 2 KaiOS-based mobile device (this is just a repost of the original found on the NCC Group research page). The magickey PIN bypass is probably my favorite since it is a cute bug, but the ability to reconfigure OTA properties remotely via the browser is a bit more impactful.
 Alcatel Flip 2 Local Privilege Escalation (CVE-2019-16242) Alcatel Flip 2 OTA Update Settings Configurable By Untrusted JavaScript (CVE-2019-16243) Alcatel Flip 2 PIN Authentication Bypass (CVE-2019-16241)  &amp;nbsp;</description>
    </item>
    
    <item>
      <title>Cloudiot Write-ups (Internal NCC Group CTF 2019)</title>
      <link>https://d3adend.org/blog/posts/cloudiot-write-ups/</link>
      <pubDate>Wed, 05 Jun 2019 19:47:11 +0100</pubDate>
      
      <guid>https://d3adend.org/blog/posts/cloudiot-write-ups/</guid>
      <description>NCC Group holds an internal security conference each year and the last con included a CTF that I participated in. Big props to Dan Helton for putting it together an enjoyable CTF that went smoothly. The CTF consisted of a handful of servers that participants had to break into in order to acquire enumeration, foothold, and root flags. Additionally, there were other challenges related to crypto and forensics.
The following are writeups for all the servers describing how I acquired the foothold and root flags.</description>
    </item>
    
    <item>
      <title>Argument Injection Hammer Burp Suite Extension</title>
      <link>https://d3adend.org/blog/posts/argument-injection-hammer/</link>
      <pubDate>Fri, 17 May 2019 14:47:27 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/argument-injection-hammer/</guid>
      <description>I wrote a short blog post describing a Burp Suite extension that I developed here. This is just a repost originally hosted on the NCC Group research page&amp;hellip;
Argument Injection Hammer is an extension for the intercepting proxy Burp Suite. I wrote the extension in order to enhance the ability of the proxy to detect argument injection and manipulation vulnerabilities in web applications.
The extension contains payloads that can detect argument injection and manipulation vulnerabilities associated with common Linux commands using both in-band detection techniques and timing-based detection techniques.</description>
    </item>
    
    <item>
      <title>Microcorruption Write-ups (1 - 10)</title>
      <link>https://d3adend.org/blog/posts/microcorruption-write-ups-1-10/</link>
      <pubDate>Tue, 02 Oct 2018 01:41:44 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/microcorruption-write-ups-1-10/</guid>
      <description>When the Microcorruption game first came out I beat the first sixteen levels and then I got stumped on the alphanumeric MSP430 shellcode level (damn MSP430 instructions). I started to go through the game again to beat more levels and take notes to reenforce my own knowledge of the subject. I suggest everyone check out the game first if you&amp;rsquo;re interested in learning about different exploitation techniques (stack overflows, heap overflows, format string vulnerabilities, etc.</description>
    </item>
    
    <item>
      <title>Dialogic PowerMedia XMS Multiple Vulnerabilities</title>
      <link>https://d3adend.org/blog/posts/dialogic-powermedia-xms-multiple-vulnerabilities/</link>
      <pubDate>Sun, 24 Jun 2018 17:57:50 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/dialogic-powermedia-xms-multiple-vulnerabilities/</guid>
      <description>I disclosed multiple vulnerabilities to Dialogic in their PowerMedia XMS product (version 3.4), which is a &amp;ldquo;highly scalable, software-only media server that enables standards-based, real- time multimedia communications solutions for IMS, MRF, Enterprise, and WebRTC applications on premise or in the cloud.&amp;rdquo;
 CVE-2018-11634 - Plaintext storage of passwords in a SQLite database. CVE-2018-11635 - Use of a hard-coded cryptographic key used to protect cookie session data allows remote attackers to bypass authentication.</description>
    </item>
    
    <item>
      <title>Maxthon Browser Arbitrary File Write, Login Page UXSS, and SQL Injection</title>
      <link>https://d3adend.org/blog/posts/maxthon-browser-arbitrary-file-write-login-page-uxss-and-sql-injection/</link>
      <pubDate>Thu, 10 Nov 2016 21:31:16 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/maxthon-browser-arbitrary-file-write-login-page-uxss-and-sql-injection/</guid>
      <description>Maxthon Browser is another popular Android browser that is used instead of the stock browser. I have identified a number of interesting, and severe, vulnerabilities in the Android version of the browser that could result in remote code execution and information leakage.
 Exposed JavaScript Interface allows for arbitrary file writes - A malicious webpage can force the browser to download a zip file, which the browser will put onto the SD card and unzip, by calling the installWebApp method with the desired URL.</description>
    </item>
    
    <item>
      <title>React Native Development Server Remote OS Command Injection and Remote File Disclosure</title>
      <link>https://d3adend.org/blog/posts/react-native-development-server-remote-os-command-injection-and-remote-file-disclosure/</link>
      <pubDate>Thu, 12 May 2016 02:52:45 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/react-native-development-server-remote-os-command-injection-and-remote-file-disclosure/</guid>
      <description>React Native is another cross-platform mobile development framework created by Facebook that developers can use to develop mobile applications on the Android and iOS platforms using JavaScript. From an architectural standpoint the framework is closer to Titanium or Kony than Cordova given that the mobile application uses JavaScriptCore as a standalone JS engine to execute the JS application code and the UI would be composed of native UI components as opposed to a HTML-based UI rendering in a WebView used in Cordova-based applications.</description>
    </item>
    
    <item>
      <title>Android Anti-Hooking Techniques in Java</title>
      <link>https://d3adend.org/blog/posts/android-anti-hooking-techniques-in-java/</link>
      <pubDate>Wed, 23 Dec 2015 21:08:37 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/android-anti-hooking-techniques-in-java/</guid>
      <description>A recent internal thread about detecting hooking frameworks in native code (C/C++) got me thinking about the different ways that a Java Android application can detect the presence of either Cydia Substrate or the Xposed framework.
Disclaimer: All of these anti-hooking techniques are easy to bypass by any experienced reverse engineer. I&amp;rsquo;m just exploring how one might go about detecting that their Java application has been hooked using Substrate or the Xposed framework because at some point we will need to be able to bypass these techniques to do our jobs just like how we bypass root detection on a daily basis.</description>
    </item>
    
    <item>
      <title>Puffin Browser RCE and Remote File Disclosure</title>
      <link>https://d3adend.org/blog/posts/puffin-browser-rce-and-remote-file-disclosure/</link>
      <pubDate>Tue, 08 Dec 2015 22:55:52 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/puffin-browser-rce-and-remote-file-disclosure/</guid>
      <description>As part of my research into the Intent.parseUri function, I identified that the Android version of the Puffin Browser was vulnerable to remote code execution, on 4.4.3 devices and below, and remote file disclosure, on any device, due to a number of factors including improper intent URI scheme parsing.
The parseUri function is often used by Android browsers, or Android applications with WebView components, in order to support the intent URI scheme.</description>
    </item>
    
    <item>
      <title>Abusing UIWebView baseURL settings in the Cordova ChildBrowser Plug-in</title>
      <link>https://d3adend.org/blog/posts/abusing-uiwebview-baseurl-settings-in-the-cordova-childbrowser-plug-in/</link>
      <pubDate>Fri, 03 Apr 2015 13:11:20 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/abusing-uiwebview-baseurl-settings-in-the-cordova-childbrowser-plug-in/</guid>
      <description>The ChildBrowser plug-in is a popular third-party plug-in that allows displaying untrusted external websites within a Cordova-based application. It is very similar to the core InAppBrowser plug-in, which is the plug-in that Apache currently recommends using, since they both create a separate WebView instance that does not expose native mobile APIs to the untrusted HTML/JavaScript. Last year I disclosed a vulnerability that allowed the untrusted JavaScript in the InAppBrowser WebView to inject in JavaScript into the trusted Cordova WebView, which allowed for abusing of native mobile APIs remotely.</description>
    </item>
    
    <item>
      <title>Javelin Browser RCE and Password Manager Information Disclosure</title>
      <link>https://d3adend.org/blog/posts/javelin-browser-rce-and-password-manager-information-disclosure/</link>
      <pubDate>Thu, 02 Apr 2015 13:28:57 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/javelin-browser-rce-and-password-manager-information-disclosure/</guid>
      <description>&lt;p&gt;There exists a number of third-party browsers in use on Android devices besides the stock browser and Chrome.  PhoneArena provided a feature comparison and performance comparison of the &lt;a href=&#34;http://www.phonearena.com/news/The-best-Android-browsers-2014-edition-design-features-and-performance_id58350&#34;&gt;&amp;ldquo;best&amp;rdquo; Android browsers in 2014&lt;/a&gt;, but I wasn&amp;rsquo;t familiar with a number of the browsers on the list so decided to take a look at the security of a few of them.  The first one that I looked at named Javelin, previously known as Jerky due to its privacy features (not joking), and I identified that it was vulnerable to remote code execution due to improper use of the WebView &lt;code&gt;addJavascriptInterface&lt;/code&gt; function on Android devices running a version less than 4.2.  On Android devices running 4.2 and above, it shouldn&amp;rsquo;t be possible to use reflection to instantiate arbitrary classes, and invoke arbitrary functions, but we can still abuse the injected Java objects to acquire the passwords stored in the browser&amp;rsquo;s password manager remotely.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Cordova LaunchMyApp Plug-in Remote JavaScript Injection</title>
      <link>https://d3adend.org/blog/posts/cordova-launchmyapp-plug-in-remote-javascript-injection/</link>
      <pubDate>Wed, 17 Dec 2014 19:29:26 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/cordova-launchmyapp-plug-in-remote-javascript-injection/</guid>
      <description>The Cordova mobile application development framework does not support launching a mobile application via a custom URI scheme, such as someurischeme://pathhere/?param=somedata, out of the box on all of its supported platforms, which is somewhat surprising for a cross-platform mobile framework. Notably missing is support for custom URI schemes in the Android version of the framework, although custom URI schemes are supported by the iOS version of the framework. This has driven developers using the Cordova framework to either develop their own custom Cordova plug-ins to add support for this IPC mechanism or use an open-source 3rd party Cordova plug-in.</description>
    </item>
    
    <item>
      <title>Exploitation of Open URL AJAX Requests and DOM-based XSS using CORS</title>
      <link>https://d3adend.org/blog/posts/exploitation-of-open-url-ajax-requests-and-dom-based-xss-using-cors/</link>
      <pubDate>Tue, 09 Dec 2014 22:13:07 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/exploitation-of-open-url-ajax-requests-and-dom-based-xss-using-cors/</guid>
      <description>I noticed a couple somewhat interesting vulnerabilities earlier this year that require the use of cross-origin resource sharing to exploit. Consider the following JavaScript code and assume that the getQueryString function returns the value of the &amp;ldquo;someUrl&amp;rdquo; parameter in the query string by parsing the document.location object. In the vulnerable page, the web application asks the user for sensitive data such as their name, credit card, and address, and the client-side JavaScript code submits this information via an AJAX request using the jQuery JavaScript library.</description>
    </item>
    
    <item>
      <title>Understanding Fragment Injection</title>
      <link>https://d3adend.org/blog/posts/understanding-fragment-injection/</link>
      <pubDate>Wed, 18 Jun 2014 19:55:54 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/understanding-fragment-injection/</guid>
      <description>A colleague asked me about an Android vulnerability called fragment injection because of an article he read [1] and I think its worth diving into the details of the vulnerability. Fragment injection is a classic example of using reflection in an unsafe way (CWE-470) [2]. As in untrusted data from an Intent is used to determine which class is instantiated within the target Android application.
In order to understand fragment injection, we have to review Google&amp;rsquo;s PreferenceActivity class.</description>
    </item>
    
    <item>
      <title>Cordova InAppBrowser Remote Privilege Escalation</title>
      <link>https://d3adend.org/blog/posts/cordova-inappbrowser-remote-privilege-escalation/</link>
      <pubDate>Mon, 14 Apr 2014 12:11:49 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/cordova-inappbrowser-remote-privilege-escalation/</guid>
      <description>Earlier this year, I identified an interesting vulnerability (CVE-2014-0073) in one of Apache Cordova&amp;rsquo;s core plug-ins (InAppBrowser). Cordova, also sometimes referred to as PhoneGap, is a popular cross-platform mobile framework that allows developers to write mobile applications in JavaScript and HTML. The JavaScript and HTML code executes within the Cordova WebView and has access to native functionality via a set of plug-ins that is exposed by a JavaScript bridge. How this bridge is implemented varies across the supported platforms such as Android, iOS, Windows Phone, and BlackBerry.</description>
    </item>
    
    <item>
      <title>Why cross-domain policy files are occasionally interesting to look at.</title>
      <link>https://d3adend.org/blog/posts/why-cross-domain-policy-files-are-occasionally-interesting-to-look-at/</link>
      <pubDate>Tue, 23 Jul 2013 22:15:39 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/why-cross-domain-policy-files-are-occasionally-interesting-to-look-at/</guid>
      <description>A cross-domain policy file grants a web client such as a Flash application or a Siverlight application the ability to make a cross-domain request and access the response. As in it allows a Flash application on www.evil.com to make a HTTP request to www.bank.com and read the HTTP response, which may allow an attacker to acquire sensitive information (account information, sensitive messages, CSRF tokens, other junk, etc.) assuming the victim is logged into www.</description>
    </item>
    
    <item>
      <title>Abusing WebView JavaScript Bridges</title>
      <link>https://d3adend.org/blog/posts/abusing-webview-javascript-bridges/</link>
      <pubDate>Fri, 21 Dec 2012 19:50:36 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/abusing-webview-javascript-bridges/</guid>
      <description>&lt;p&gt;Android applications often use the &lt;a href=&#34;http://developer.android.com/reference/android/webkit/WebView.html&#34; title=&#34;WebView&#34;&gt;WebView&lt;/a&gt; class to embed a browser component within an &lt;a href=&#34;http://developer.android.com/reference/android/app/Activity.html&#34; title=&#34;Activity&#34;&gt;Activity&lt;/a&gt; in order to display online content.  For example, the following code will show the Google homepage within an Activity.&lt;/p&gt;
&lt;pre&gt;
WebView webView = new WebView (R.id.webView1);
webView.getSettings().setJavaScriptEnabled(true);
webView.loadUrl(&#34;http://www.google.com&#34;);
&lt;/pre&gt;
&lt;p&gt;An application can inject Java objects into a WebView via the [addJavascriptInterface](&lt;a href=&#34;http://developer.android.com/reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,&#34;&gt;http://developer.android.com/reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,&lt;/a&gt; java.lang.String) &amp;ldquo;addJavascriptInterface&amp;rdquo;) function.  This allows JavaScript code to call the public methods of the injected Java object.  Exposing Java objects to JavaScript could have some negative security implications, such as allowing JavaScript to invoke native phone functionality (sending SMS to premium numbers, accessing account information, etc.) or allowing JavaScript to subvert existing browser security controls such as the same origin policy.  I could not find much information documenting how to exploit these issues, but an academic paper titled &lt;a href=&#34;http://www.cis.syr.edu/~wedu/Research/paper/webview_acsac2011.pdf&#34; title=&#34;Attacks on Webview in the Android System&#34;&gt;Attacks on WebView in the Android System&lt;/a&gt; explores a number of attacks and describes a situation in which a file utilities object is exposed to JavaScript code thus allowing attackers to manipulate the file system if an attacker can control any of the content rendered in a WebView via MiTM, JavaScript injection, or redirection attacks.&lt;/p&gt;
&lt;pre&gt;
// Java code
wv.addJavascriptInterface(new FileUtils(), &#34;FUtil&#34;);
...
&amp;lt;!-- JavaScript code --&amp;gt;
&amp;lt;script type=&#34;text/javascript&#34;&amp;gt;// &amp;lt;![CDATA[
filename = &#39;/data/data/com.livingsocial.www/&#39; + id +&#39;_cache.txt&#39;;
FUtil.write(filename, data, false);
// ]]&amp;gt;&amp;lt;/script&amp;gt;
&lt;/pre&gt;
&lt;p&gt;The paper goes on to state that “in our case studies, 30% Android apps use addJavascriptInterface. How severe the problems of those apps are depends on the types of interfaces they provide and the permissions assigned to them.”  The following code exposes the &lt;code&gt;SmokeyBear&lt;/code&gt; class to JavaScript, but only declares one public function that returns a string.  Is this interface safe to expose?&lt;/p&gt;
&lt;pre&gt;
webView.addJavascriptInterface(new SmokeyBear(), &#34;SmokeyBear&#34;);
...
public class SmokeyBear {
	public String getAdvice() {
		return &#34;Only You Can Prevent Wildfires.&#34;;
	}
}
&lt;/pre&gt;</description>
    </item>
    
    <item>
      <title>Content-Type Blues</title>
      <link>https://d3adend.org/blog/posts/content-type-blues/</link>
      <pubDate>Wed, 29 Feb 2012 07:12:28 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/content-type-blues/</guid>
      <description>Assuming an attacker can control the start of a CSV file served up by a web application, what damage could be done? The example PHP code below serves up a basic CSV file, but allows the user to control the column names. Note that the Content-Type header is at least set properly.
&amp;lt;?php header(&#39;Content-Type: text/csv&#39;); header(&#39;Content-Disposition: inline; filename=blah.csv&#39;); header(&#39;Content-Length: &#39; . 20); echo $_GET[&#34;columnNames&#34;] . &#34;\r\n&#34;; echo &#34;1,2,3,4,5\r\n&#34;; echo &#34;data,we,do,not,control&#34;; ?</description>
    </item>
    
    <item>
      <title>Bypassing Flash’s local-with-filesystem Sandbox Redux</title>
      <link>https://d3adend.org/blog/posts/bypassing-flashs-local-with-filesystem-sandbox-redux/</link>
      <pubDate>Mon, 12 Dec 2011 02:27:21 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/bypassing-flashs-local-with-filesystem-sandbox-redux/</guid>
      <description>I suppose I should explain what Adobe refers to as a security control bypass (CVE-2011-2429). There exists a number of different security sandboxes that the Flash Player uses to restrict SWFs. In this case, I was able to create a SWF that bypassed the restrictions imposed by a local-with-filesystem sandbox.
&amp;ldquo;The local-with-filesystem sandbox&amp;ndash;For security purposes, Flash Player places all local SWF files and assets in the local-with-file-system sandbox, by default. From this sandbox, SWF files can read local files (by using the URLLoader class, for example), but they cannot communicate with the network in any way.</description>
    </item>
    
    <item>
      <title>Don&#39;t Believe Everything You Read</title>
      <link>https://d3adend.org/blog/posts/dont-believe-everything-you-read/</link>
      <pubDate>Tue, 06 Dec 2011 12:53:13 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/dont-believe-everything-you-read/</guid>
      <description>Searching for &amp;ldquo;how to prevent cross site scripting in .NET&amp;rdquo; in Google produces a number of interesting results. The first link points to a MSDN article titled How To: Prevent Cross-Site Scripting in ASP.NET, but this article includes the following code snippet, which &amp;ldquo;uses HtmlEncode to ensure the inserted text is safe&amp;rdquo;, but this code is clearly vulnerable upon further inspection.
&amp;lt;%@ Page Language=&amp;ldquo;C#&amp;rdquo; AutoEventWireup=&amp;ldquo;true&amp;rdquo;%&amp;gt;
 &amp;lt;html&amp;gt; &amp;lt;form id=&#34;form1&#34; runat=&#34;server&#34;&amp;gt; &amp;lt;div&amp;gt; Color:&amp;amp;nbsp;&amp;lt;asp:TextBox ID=&#34;</description>
    </item>
    
    <item>
      <title>No Love for the Null Byte</title>
      <link>https://d3adend.org/blog/posts/no-love-for-the-null-byte/</link>
      <pubDate>Thu, 22 Sep 2011 05:23:32 +0800</pubDate>
      
      <guid>https://d3adend.org/blog/posts/no-love-for-the-null-byte/</guid>
      <description>Attackers have commonly used the null character to bypass file extension restrictions during the exploitation of local file inclusion vulnerabilities. rain.forest.puppy outlined this type of attack against Perl-based CGI applications in Phrack issue 55 over ten years ago, but the problem has also affected web applications written in other higher-level languages such as Java, .NET, and PHP. Consider the following insecure PHP code. if(file_exists(&#39;/tmp/&#39;.$_GET[&#39;filename&#39;].&#39;.txt&#39;)) { include &#39;/tmp/&#39;.$_GET[&#39;filename&#39;].&#39;.txt&#39; }  Clearly, an attacker could abuse the poorly written application to include arbitrary TXT files stored on the web server, which is certainly not good, but until fairly recently an attacker could also include any file regardless of the extension.</description>
    </item>
    
  </channel>
</rss>
