Elusive Thoughts

This article is the second part of OWASP top 10 Common vulnerabilities... HTTP Header Injection Vulnerability Description:  This post is the second part of the series OWASP what? and focuses explaining how OWASP categorizes vulnerabilities. So HTTP header injection is a general class of web application security vulnerability which occurs when Hypertext Transfer Protocol (HTTP) headers are dynamically generated based on user input. Header injection in HTTP responses can allow for HTTP response splitting, Session fixation via the Set-Cookie header, cross-site scripting (XSS), and malicious redirects attacks via the location header. HTTP header injection is a relatively new area for web-based attacks, and has primarily been pioneered by Amit Klein in his work on request/response smuggling/splitting. During the web application penetration test, we managed to successfully inject HTTP headers on to the server’s responses. Impact: Various kinds of attack can be delivered via...

For a long time now... For a long time now there is a confusion about the common web application vulnerabilities and their countermeasures. This is post is going to clear out the meaning of some of the OWASP top 10 web app vulnerability categorization and provide you with countermeasures (it is going to be a long post). The OWASP top 10 describes the most common web application vulnerabilities based on the risk, In order to clarify what Risk is and how is perceived from OWASP I am going to give you the definition of risk, so risk is: "Risk is the potential that a chosen action or activity (including the choice of inaction) will lead to a loss (an undesirable outcome). The notion implies that a choice having an influence on the outcome exists (or existed). Potential losses themselves may also be called "risks". Almost any human endeavor carries some risk, but some are much more risky than others." [1] The maths of risk is: Risk = (probability of accident...

Pre-requisite : You need to have JDK and Burp installed on your system. Create a working directory called “burp_extension” and create the source file “BurpExtender.java” in the same directory. Here, in this example, the source file would contain both the above classes. Create a directory called “burp” inside the directory “burp_extension” and copy the interface source code files i.e., IBurpExtenderCallbacks, IMenuItemHandler ,etc., provided by Burp. Your extension will look for these files in that path. Also, make sure your “BurpExtender.java” file has this line to import burp package :- Import burp.*; Now, compile the BurpExtender.java file using javac and create a jar file out of both the class files generated by compilation. D:\burp_extension>”C:\Program Files\Java\jdk1.6.0_29\bin\javac.exe” BurpExtender.java D:\burp_extension>”C:\Program Files\Java\jdk1.6.0_29\bin\jar.exe” -cf burpextender.jar BurpExtender.class extendedMenuItem.class Now, burpextender.jar has be...

Sometime ago, many security focused sites and mailing lists were abuzz with the release of a new tool called ShellCodeExec that has the ability to execute alpha numerically created shellcode (as commonly generated with the Metasploit Framework) the link to the tool can be found here . Can be compiled and works on POSIX (Linux/Unices) and Windows systems. Can be compiled and works on 32-bit and 64-bit architectures. Works in DEP/NX-enabled environments: it allocates the memory page where it stores the shellcode as +rwx - Readable Writable and eXecutable. It supports alphanumeric encoded payloads: you can pipe your binary-encoded shellcode (generated for instance with Metasploit's msfpayload) to Metasploit's msfencode to encode it with the alpha_mixed encoder. Set the BufferRegister variable to EAX registry where the address in memory of the shellcode will be stored, to avoid get_pc() binary stub to be prepended to the shellcode. Spawns a new thread where the shellcod...