Well.. sort of. Has this happened to you? You need to fill out an application form supplied in PDF format only to find out that you cannot edit the document. So you need to print out the file, write in the information and either mail it or scan the document for emailing. This is when I wish I had a PDF editor. But there are no reliable freeware PDF editors out there and buying licenses for commercial ones are expensive.
Here’s a little trick that shows how you can edit and write PDF files using a combination of freeware tools available for Windows.
Click on the “Typewriter” tool in the top row of icons. You will now be able to type in the PDF document. Just click and start typing into the document.
FoxIt will not allow you to save the edited document without a license.
Instead, go to File –> Print and select “PDFCreator”. This will start up PDFCreator and print a new document for you.
You now have a edited PDF file without spending any money on expensive PDF writer licenses.
Cross Site Scripting (XSS) vulnerability is one of the most prevalent security issue today. Prevention of XSS is pretty straightforward if you know the different options available to you. Let’s look at 3 easy options when using the .NET framework.
.NET "ValidateRequest" Approach Microsoft introduced ValidateRequest in .NET 1.1. The idea is that the framework checks incoming requests for any constructs indicative of Cross Site Scripting issues. If any problems are found, an error is raised and the request does not even get to the web application. The directive can be placed in Machine.config, web.config or at the page level. This option is turned on by default in ASP.NET. Microsoft has made it clear that you should not rely ONLY on this method:
Do not rely on ASP.NET request validation. Treat it as an extra precautionary measure in addition to your own input validation.
It is clear why Microsoft adds the precaution. This is a blacklist based approach and every blacklist has limitations. In addition, if there is a business need to use constructs that are blacklisted by validateRequest (e.g., Ajax apps that send xml back and forth), you may need to turn off this feature. Lets check what validateRequest does by cracking open the relevant dll’s.
.NET Framework 1.1 does the following checks as seen from the disassembly: Reading through the code, we see that the following items are checked - expression strings, JavaScript script and OnXXX handlers, ‘<’ followed by alpha characters and "&#". It is a decent list that catches most common XSS vectors.
.NET Framework 2.0 does the following checks as seen from the disassembly: In this case, the following items are checked - ‘<’ followed by alpha characters and "&#". It appears that MS decided to dumb down request validation when .NET framework went from 1.1 to 2.0. An important point to remember about "validateRequest" is that these protections are given to only certain parts of the request. Query Strings, Form variables and Cookies are protected. Header values, Server Variables, viewstate, information inside multi-part forms (e.g., file upload) are not validated.
From a developer’s perspective, the usefulness of this class is limited by the fact that it cannot be overridden or extended.
Anti-XSS Library The Anti-XSS library is an exhaustive blacklist. The following screenshot shows all function calls in the library (ver 1.5). As seen in the disassembly above, the coverage of Anti-XSS library is quite good as it looks at JavaScript, VbScript, XML. Being a public class, it is possible to extend and override methods to suit your application needs.Use of this library entails downloading the latest dll and adding a reference to your web application project.
Output Encoding This method involves the use of HttpUtility.HtmlEncode() call whenever you send information to the presentation layer. This process is not as automatic as the first two methods because the developer has to be more aware of where they are displaying data.
There has been a lot of talk lately about what people perceive to be a problem with the Payment Card Industry (PCI) standard. PCI Council kicked up dust with their recent clarification about section 6.6:
Most of the security folks are peeved by the fact that an application firewall can be used in place of a code review. I agree with the nay-sayers from a purely technical perspective. Application firewalls do not protect you from attacks for which you cannot write good signatures…and there are many, many attacks that fall in this category (authentication, authorization etc, etc). Even for attacks such as SQL Injection and Cross Site Scripting, which the WAP are designed to mitigate, there may be new ways to circumvent the firewall. So, from a technical perspective it is pretty ineffective if an organization is pushing for security.
There lies the big problem. Most organizations do not really care about security. Customer data is just one piece of the puzzle to get their business done. The only reason companies take customer data seriously is because there are laws and the reputation loss. From a business and process perspective, it is just one cog of many. They know there is something called PCI and there are a few requirements to be met. And the PCI Council has given these companies a freebie in the form of web application firewall.
In my view, the whole issue about section 6.6 has to be taken in perspective. If an organization is to pass PCI requirements, they need to satisfy all sections. In other words, the PCI requirements also stipulate a lot of best practices - network segmentation (Req. 1), separation of duties (Req.6.3), good programming practices [OWASP Top 10] (Req.6.5), Regular vulnerability testing (Req.11) that needs to be satisfied. If a company wants to be PCI Compliant, they would ideally look at all of these and, in the process become compliant. Viewed in this light, the issue of web application firewall is a small one.