This was one of many tricks I was treated to on Monday night. I saw Cap Diebel of Denim Group (pictured at right) speak on security in the ASP.NET space at the Austin .NET Users Group. He used OWASP's ZAP (Zed Attack Proxy) to record HTTP requests and then doctor them up and resend them reshaped in the name of pen testing and he suggested that Barb and Sweet (hope I have those names right) were similar tools. He suggested that the validator controls in web forms were a very good thing to embrace and beyond this in a bigger way seemed to prefer web forms to MVC. He said that early versions of MVC had a gremlin in which the Anti-CSRF (!Cross-Site Request Forgery) token will be checked to see if it exists but not if it belongs to the right person. He offered that ASP.NET in general, not just web forms, offers the best out-of-the-box security of any framework, but yet cautioned that there is still plenty to worry about. He detailed nine "Domains of Application Security" as he saw them. They were as follows:
- Trust Boundaries
_EventValidation is a token that one may use to verify that a web form, when posted to, was posted to from itself as opposed to from elsewhere. This can guard against faking/forcing the button click of a disabled button.
<pages enableEventValidation="false" />
...goes in Web.config inside the system.web stuff if you want to explicitly turn it off. You have to explicitly turn off the event validation in AngularJS apps that tie into .NET. Angular oversteps. The ViewState is Base64 encoded. If you do security checks inside of your Page_Load event make sure you do it every time. Do not conditionally sidestep it in the Page.IsPostBack scenarios. ASP.NET Sessions are really just kept in cookies and when "logging out" of a web app it has been recommended that one go about it like so:
Session.Abandon();
Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", ""));
However, Cap suggested that SessionIDManager is the more modern way to go about this. His code snippet looked like this:
SessionIDManager Manager = new SessionIDManager();
string newSessionID = Manager.CreateSessionID(Context);
Manager.SaveSessionID(Context, newSessionID, out redirected, out isAdded);
- Authentication
Be sure your client's claim ticket distinguishes who they are, why they are there, and what application they are authenticated for. Claims-based authentication is Microsoft's way of doing OAuth type stuff. The code snippet that Cap had for it looked like this:
[RoutePrefix("api/claims")]
public class ClaimsController : BaseApiController
{
[Authorize]
[Route("")]
public IHttpActionResult GetClaims()
{
var identity = User.Identity as ClaimsIdentity;
var claims = from c in Identity.Claims
select new
{
subject = c.SubjectName,
type = c.Type,
value = c.Value
};
return Ok(claims);
}
}
- Authorization
ACLs (Access Control Lists) are probably fine. Some of Cap's configuration markup for as much looked like this:
<configuration>
<system.webServer>
<security>
<authorization>
<remove users="*" roles="" verbs="" />
<add accessType="Allow" users="" roles="Staff" />
</authorization>
</security>
</system.webServer>
</configuration>
How can you keep inappropriate users from accessing uploaded PDFs? I once worked on an app where the solution was to associate the PDFs with the wrong mime type in IIS and then fix the problem conditionally, but Cap's solution was to build a page whose sole purpose is to stream PDFs in a response. By the way, what if someone is uploading the PDFs so that they may be downloaded? You probably want to put a limit on the size of what can be shoved up to your hosting. It's hard to fill up memory and kill it in an attack, but Disk I/O is pretty easy to abuse if an avenue for abuse is provided.
- Input Validation
Use positive validation for inputs. Screen for what you want and not what you don't want (negative validation). How do you do this? That's right. You use regular expressions. The .NET Validator Framework will perform RegEx validations both client-side and server-side. SDL Regex Fuzzer is a tool Cap suggested using to see if regular expressions are wasteful. For example:
^[hc]at
...is going to match against either "hat" or "cat" and as it has a finite length it has a pretty great shape, however...
^(\d+)^$
...can match any length of digits greater than zero (replace the + with a * to match ANY number of digits) and thus can spin and spin trying to validate a sinister input that is really long!
- Information and Error Handling
If one injects a script tag with...
document.body.innerHTML = whatever;
...in it they may rewrite your page should the contents bubble back up in a Literal or a Label in web forms because both of these controls allow for HTML to be interpreted as HTML and, hence, a script tag may be injected.
- Non-Repudiation and Auditing
Be wary of attempts to inject something into your logs to making the logging stop to hide a problem downstream! log4net will only end a log file if the file size is too big and that should be the standard for as much, but a more Mickey Mouse solution may come with some pitfalls! The Event Viewer is not a good triage tool. You need logs of your own beyond those for IIS.
- Data Protection
Don't put the encryption key for your password hashing in Web.config. It should be kept in a tightly controlled directory or as a registry key. Don't get creative and write your own algorithm for password hashing and don't use an existing implementation that is dated.
- Configuration and Deployment
Sign assemblies to protect your Microsoft intermediate language (MSIL) code.
- Defense in Depth
Don't rely on one safeguard! Two backend systems which talk only to each other and do so behind a firewall should, nonetheless, do so securely. Don't bank exclusively on the firewall's protection, etc.
No comments:
Post a Comment