Web applications have always been threatened by a series of attacks. Thankfully, IT Security organizations have worked tirelessly to secure web application development by coming up with ways to mitigate malicious attacks. One of these developments is the Microsoft Web Protection Library, a tool that can be used to protect ASP.NET web application and Windows applications malicious attacks

In this article, we are going to learn about Microsoft Web Protection Library. We will first look at threats surrounding web applications and then delve into the protection measures that WPL introduces.
 
What is the Microsoft Web Protection Library (WPL)?
The WPL is a set of .NET assemblies put together for protection against the most common attack vectors. WPL comprises the Anti-XSS which is a bunch of encoding functions for user input which includes JavaScript, XML, CSS, HTML, and HTML attributes. WPL also has a Security Runtime Engine which works as a shield protecting web applications from the common attack vectors.
 
The Anti-XSS Library
A cross-site script (XSS) attack is a very common attack that involves malicious user input (e.g. in the form of scripts) from attackers using poorly validated form fields on web applications. Anti-XSS provides a class that can be used to encode all user input on forms in MVC, web pages, and web forms applications. It uses a white-list approach which entails that it checks the expected input from users and if not recognized it classifies that input as a possible danger or possible harm. It comprises of encoders for:
    HTML
    HTML Attributes
    CSS
    XML
    JavaScript

Anti-XSS Examples
ASPX
<td><asp:Label id='lblIDNO' runat='server'></asp:Label></td>
 
ASPX.CS
lblIDNO.Text = Request['IDNO'];
 
Normally an unsafe way of rendering can be done as in the above codes snippet but Anti-XSS provides a safe way using the HTML encoding.
 
ASPX
<td><asp:Label id='lblIDNO' runat='server'></asp:Label></td>
 
ASPX.CS
lblIDNO.Text = Microsoft.Security.Application.Encoder.HtmlEncode(Request['IDNO']);
 
In the above code, the dynamic IDNumber property is being encoded using the Anti-XSS HTML encoder before it is put in the HTML context. The same could be done using a shortcut ()
 
The code below shows an example of JavaScript encoding:
<a onclick='<%# string.Format('isDelete({0})', Microsoft.Security.Application.Encoder.JavaScriptEncode(Item.Address)) %>'>Delete</a>
 
Scripts should also be encoded just in case an attacker uses a malicious script that might end up executing unwanted commands at the server-side.
 
Dynamic data including URLs should be encoded before they are written in href because they may contain malicious input or untrusted URL and end up exfiltrating data to attacker sites.
 
The following code shows an example of URL encoding using WPL:
<a href=<%# Microsoft.Security.Application.Encoder.UrlEncode(Item.Url) %>>Customer Details</a>
 
It very important that developers understand the various malicious vectors used by attackers which can be implemented using threat modeling at design time. Safety can be applied to applications at development time or to existing applications and developers need to review code which gives users output, determine if the given output has any untrusted input parameters, also understand the context in which untrusted input is being compromised to give output and lastly encode the output properly. WPL uses the whitelist approach and when it is not sure that the input is trusted or not, it assumes that it is not and rejects the input as untrusted. Most potential dangers are found in form fields, query strings, and cookie contents.
 
In order to use Anti-XSS encoders after installation of WPL, you need to make use of the following directive:
using Microsoft.Security.Application;
 
WPL Architecture
The following is a diagram that shows the architectural pattern of the WPL.

The impact that can be caused by malicious attacks on businesses and individuals is so great that it is very important that developers and analysts try to find all possible vulnerabilities and not overlook certain aspects of the application. WPL is an effective tool for protecting individuals as well as organizations from such devastating web attacks.

Why merge different documents?
There are a lot of common yet crucial reasons to merge documents. Let's understand the need with some use-cases.
 
Real estate
When you buy or lease a property, you have to go through a lot of documentation (e.g. mortgage, loan application, agreements, various expense recordings). Such documentation is mostly recorded in multiple file formats (e.g. PDF, Word, Excel, Presentation). Wouldn't it be super if you could compile all the documents into a single understandable format such as PDF?
 
Archived documents
Most of the time we have a lot of electronic documents saved in various formats. They all have similar content and need to be combined. For example Excel file with charts, or Word file swith some formatted text. These details could be combined in a single PDF. Eventually, you can share this resultant PDF with colleagues or print it without any issue.
 
Merge documents to PDF
 
Let's see how we merge DOC, PPT, XLS and PDF files into a single PDF.
    using (Merger merger = new Merger(@"c:\document1.pdf"))  
    {  
        merger.Join(@"c:\document2.doc");  
        merger.Join(@"c:\document3.ppt");  
        merger.Join(@"c:\document4.xls");  
        merger.Save(@"c:\merged.pdf");  
    }  

Download the DLL and add it as a reference in your .NET project (existing or new).