While rewriting programs that had hundreds of critical security issues, I turned towards ASP MVC.
Not only are there security issues in these websites, but with many sites filled with security issues, many of the normal features start to become broken and unusable over time with not being maintained well.
I turned towards the .NET 4 Framework to solve these issues because the people that I would be supporting had primarily Microsoft experience.
Although, J2EE has very similar frameworks that would have produced the same results.
The goal would simply use Server processes and Entity Frameworks as much as possible and move the code from Browser control.
ASP.NET now uses Data Annotations, are a set of attributes and classes decorate your classes with metadata. This metadata describes a set of rules that can be used to determine how a particular object should be validated.
Data Annotations can be used across the MVC pieces.
Microsoft offers a validation for CSRF, called “ValidateAntiForgeryToken”. Example code below shows it examining the data before returning it to the next view:
Microsoft’s Portable Extension Metadata, a subset of schema metadata, can be installed to add validation to the Entity Module and its entities, it installs using a VS Extension Installer, VSIX file, http://visualstudiogallery.msdn.microsoft.com/en-us/e6467914-d48d-4075-8885-ce5a0dcb744d
When setting up your first MVC program, ASP has a default .NET DB that can handle users and roles with the default Account Controller. DTSWizard is a good migration tool for moving this type of tables across SQL Server.
To set this up, run “asp_regsql.exe”, Windows/Microsoft.Net/Framework/v4…., and follow the setup instructions from the
As long as the Database is set for the ASP framework, and a default MVC 3 is created, we already have Models, Controllers, and View frameworks built by default to handle registration, LogOn, change password, Index page and Home pages.
Wow, that’s a lot of work done for a few minutes of effort.
After the default framework is established, the next step is to add, or create, controllers, and to add views.
Controller are the actions of the application.
They normally act on the GET HTTP commands to load a web page, or the POST HTTP to save the entries from a Web page that have been submitted.
The Controllers call the views by their file names and their directories, and the views know which actions to call by their file names and Controllers.
For example, the AccountController will have its pages in the /Views/Account. The LogOn.aspx will match the LogOn action in the AccountController. They must also call the same models in passing information.
In MVC, information is constantly being passed from the controller to the view, and then sometimes back to the return controller.
Let’s walk through a typical scenario, I login, passing the userid and password to the controller, the controller calls the entity and returns the user model. Then the controller redirects the page to a users homepage, passing it the user’s data, in a model, to the page.
In a typical website, this is done hundreds, maybe thousands, of times through hundreds of different controllers and pages. Doing this scenario over and over again is the essence of MVC.
Like controllers, a back channel for passing controller information to the view is through the ViewData buffer.
In the Login controller, the sending Controller, will set the ViewData[“error”] = “Bad User”;
In the LoginError page, the receiving page. it will read the data,
The previous logging and exception handling example has many hard coded pieces. Log4Net offers more de-coupling by being separated as highly configurable framework.
Even though the basic CLR logging framework can accept changes on destination through its Handler in the “logging.properties”, Log4Net offers more advanced features in its XML use of its Appender class.
Log4Net supports XML configuration and a text configuration in log4Net.properties.
Log4Net supports Appenders that will append the logs to databases, emails, files, etc. http://logging.apache.org/log4net/release/config-examples.html
Default Error pages may display unintentional information. For instance, some error pages may display database information in an exception.
An error page giving details, like a database or table name, may be more than enough to give an attacker enough information launch an attack at the website.
To correct bad error handling in pages, Tomcat, Struts and other Web engines will allow default configurations to throw a specific error page for any unknown exceptions. For instance, many Web Application Firewalls (WAFs) will generate a error page 500 “Internal Server Error” for blocking an attack.
Many web sites use the default error pages that show the user exceptions and even exceptions into the database. The database exceptions have a tendency to display table names and invalid SQL statements that can be used for further probing.
To send all errors to a custom Error page, the web.config file for IIS: