I work on an app that is scanned by the Burp tool before the code is released to production. The recent scan has resulted in OS Injection attack vulnerabilities.
In doing research the only examples of OS injection attacks I saw were for unix, java, php apps.
Are these attacks possible against an ASP.NET (MVC) application? If so, how do you mitigate this risk? Does ASP.NET (and/or MVC) itself prevent OS Injection attacks?
The framework is not vulnerable to OS injection attacks itself. It is the code that you write with this framework that can be vulnerable. For example if you have a controller action that executes a command that is passed as parameter from the outside your application immediately becomes vulnerable. Consider this example:
public ActionResult Index(string fileName, string arguments)
{
Process.Start(fileName, arguments).WaitForExit();
return View();
}
So basically no matter what framework or programming language you are using for developing your application you should never trust user input and perform proper sanitation before accepting it.
OS Injection is defined by the OWASP Foundation as follows:
Operating system commands Calling external applications from your application.
[...]
What we should be looking for are relationships between the application and the operating system. The application utilising functions of the underlying operating system.
In java using the Runtime object, java.lang.Runtime does this. In .NET calls such as System.Diagnostics.Process.Start are used to call underlying OS functions. In PHP we may look for calls such as exec() or passthru().
But of course your research already showed that.
Are these attacks possible against an ASP.NET/MVC application?
So, yes, anywhere you use, or any library you use uses System.Diagnostics.Process.Start(), either directly or indirectly supplied with user input, you're at risk.
If so, how do you mitigate this risk?
As usual, by properly escaping and sanitizing user input where necessary. This includes not only query string or route parameters, but also cookies, HTTP headers and whatnot.
Related
This is the situation:
I use a third-party library to do some SPF checks
The checks are done from an ASP.NET web site
The third-party library uses lots of 'await/async' code, although I am calling a non-async method to do it
Most of the time, w3wp (yes, the actual w3wp.exe) simply crashes with the following error ' Invalid token for impersonation - it cannot be duplicated'.
I am assuming this is because the await/async grabbed a Thread from the threadpool which has some sort of illegal / weird identity on it, so I am wondering if there's any way to call a bit of code and tell .Net to 'forget about' async/await and just run it synchronously, on the same thread.
I've found a solution: somewhere in the product the user was being impersonated with identity.impersonate(), but the impersonation context was never .undo()'d. After making sure the identity.impersonate() was properly matched by an .undo(), the problem stopped occurring.
I did try making my own SynchronizationContext, but that didn't work in this instance, as passing on the impersonation just passed on the 'illegal' impersonation context too.
I'm reading the OWIN 1.0 spec at http://owin.org/spec/owin-1.0.0.html and just can't wrap my head around how it works. I've downloaded Katana source, but that's huge and didn't help any. I'm familiar with the somewhat standard way of having a project/assembly with interfaces only, which allows to integrate two projects without direct regencies. But I can't understand how the web server will call into the web app with only Func<> and Action<> definitions.
OWIN boils down to two things:
1) an "environment" dictionary
2) a method that processes requests and sends responses.
For #1, this is just a property bag that gives you access to the request headers, request stream, response headers, response stream and server data. Think of this as your HttpContext for ASP.NET or HttpListenerContext for System.Net.HttpListener. In fact, in more recent builds of Katana (https://katanaproject.codeplex.com/, which is an open source implementation from the ASP.NET team, there have been improvements (more to come) to simplify this down to an easier to use object model, including an OwinRequest, OwinResponse, and IOwinContext.
For #2, this is often called the "AppFunc" and the signature is:
using AppFunc = Func<IDictionary<string, object>, Task>;
This signature is used for "Middleware" that is in a pipeline of request handlers or it can be the end application which is generating HTML, is a WebAPI, etc.
In Katana, there is a class you can inherit from that simplifies this signature to consume the IOwinContext I mentioned previously. Take at look at OwinMiddlware
You can also read this article which gives an overview of the Katana/OWIN effort: http://www.asp.net/aspnet/overview/owin-and-katana/an-overview-of-project-katana
OWIN just defines how the web server and web application will talk to each other. Your application must implement one side of this contact, the other side which connects to the web server must be provided by installing a NuGet package specific to the web server. There is one for IIS, one for self hosting (stand alone application) etc.
I'm having problems because of a poorly written third-party library which our system heavily depends on. This library is not thread-safe (because of some bugs and static variables) and I need to use it in a ASP.NET webservice, which handles each user request in a separate thread.
I've tried many solutions for this problem. The best solution for now is, in my opinion, let subprocesses handle the requests. One subprocess will listen and handle the requests for one user, so I can synchronize access to the library code in a per user fashion, which is much better than all that I can do when sharing static variables between requests.
How can I route requests received by IPC communication to the appropriate WebMethods without reinventing the wheel? If possible, I would like to use the classes from .Net that handle this in a normal ASP.NET webservice, but I'm having a hard time trying to find their names.
TL;DR: I have a class MyWebService (that inherits from System.Web.Services.WebService) with some methods marked with WebMethodAttribute and I want to pass a made-up HttpRequest (or HttpContext) to it and tell it "handle it like you're receiving this from a real HTTP server, despite the fact the current process is a console application".
First, you may want to consider using WCF instead of ASMX, which is a legacy technology, kept only for backwards compatibility.
Second, you have another option: ensure that only a single thread ever uses the third-party libarary at a time. Placing lock blocks around all access to the third-party library may solve the problem.
The intent is to create a set of web services that people can reuse. These services mostly interact with a backend DB creating, retreiving and processing data.
We want to expose services so that people can use to create data mashups and other applications.
End users are webpages that can be within our domain or outside our domain. For pages outside the domain we plan to release widgets that would be configured to retreive and display the data.
One requirement - application should be extremely scalable in terms of the number of users it can handle.
Our code base is .net and we are looking at ASPX webmethods (or ASHX), ASMX webmethods and WCF (starting to read up on WCF).
In terms of security/access I found that maintaining sessionid, memberships is doable in all three. WCF seems a bit complicated to setup. I could not immediately see the value of asmx when we can get all done just using a webmethod in aspx (with a little tweaking).
Also, assuming that with the ASP.NET MVC2 I might be able to get clean urls as well for these webmethods.
Questions
Which one will be the most effective in terms of performance and scalability?
Any reason why I should choose WCF or ASMX?
Thank you for taking the time to read through this post and apologies for the naive questions since I am new to .net.
EDIT I kind of understand that WCF is the way to go. Just to understand the evolution of the technologies it would be good if someone can throw light on why a aspx webmethod is different from an asmx when similar things (apart from discovery) can be accomplished by both. The aspx webmethods can be made to return data in other formats (plaintext, json). Also, it seems that we can build restful services using ashx. Apologies again for the naive questions.
You should use WCF for developing webservices in .Net. WCF is highly configurable with many options for security, transport protocols, serialization, extensions etc. Raw performance is also significantly higher. Also WCF is being actively developed and many new features being added in version 3.5 and 4. There are also variations like WCF data services and WCF RIA services. WCF 4.0 also has better REST and JSON support which you can directly use in ASP.Net / JQuery.
ASMX is considered deprecated technology and replaced by WCF. So if you are going to start new development which requires exposing reusable services, WCF is the way to go.
I am not necessarily disagreeing with previous answer. But, from a different perspective, WFC is tricky to configure. It requires bindings, endpoints, packet sizes, a lot of confussing parameters, etc in your configuration files, and there are many serialization/deserialization issues reported. Also WCF is a relatively new technology (therefore still exposed to bugs and patches needed).
The client-generated [Reference.cs] files might have unwanted interfaces, and each public property client class exposed in the WSDL gets generated with the same observer pattern that LINQ to SQL or Entity Framework uses ( OnChanged, OnChanging, etc) so this adds a lot of fat to the client code, as opposed to the traditional SOAP Web client way.
My recommendation, if you aren't using Remoting over TCP or if you don't need the 2-way notification mechanism for remote changes - all these are very cool features of WCF - you don't need to use it.
I started to use silverlight/flex and immediately bumped into the asynchronous service calling. I'm used to solving the data access problems in an OO-way with one server fetch mechanism or another.
I have the following trivial code example:
public double ComputeOrderTotal(Order order)
{
double total = 0;
// OrderLines are lazy loaded
foreach (Orderline line in order.Orderlines)
{
// Article,customer are lazy loaded
total = total + line.Article.Price - order.Customer.discount;
}
return total;
}
If I understand correctly, this code is impossible in Flex/Silverlight. The lazy loading forces you to work with callbacks. IMO the simple expample above will be a BIG mess.
Can anyone give me a structured way to implement the above ?
Edit:
The problem is the same for Flex/Silverlight, pseudo code would
do fine
Its not really ORM related but most orms use lazy loading so i'll remove
that tag
The problem is lazy loading in the model
The above example would be very doable of all data was in memory but
we assume some has to be fetched from
the server
Closueres dont help since sometimes data is already loaded and no asynchronous fetch is needed
Yes I must agree that O/R mapping is usually done on the server-side of your application.
In SilverLight asynchronous way of execution is the desired pattern to use when working with services. Why services? Because as I said before there is no O/R mapping tool at the moment that could be used on the client-side (SilverLight). The best approach is to have your O/R mapped data exposed by a service that can be consumed by a SilverLight application. The best way at the moment is to use Ado.Net DataServices to transport the data, and on the client-side to manage the data using LINQ to Services. What is really interesting about ADS (former Astoria project) is that it is designed to be used with Entity Framework, but the good folks also implemented support for IQueriable so basically you can hook up any data provider that support LINQ. To name few you can consider Linq To Sql, Telerik OpenAccess, LLBLGen, etc. To push the updates back to the server the data source is required to support the ADS IUpdateable.
You can look just exactly how this could be done in a series of blogposts that I have prepared here: Getting Started with ADO.NET Data Services and Telerik Open Access
I can't speak to Silverlight but Flex is a web browser client technology and does not have any database driver embedded in the Flash runtime. You can do HTTP protocol interactions to a web server instead. It is there in the middle-tier web server where you will do any ORM with respect to a database connection, such as Java JDBC. Hibernate ORM and iBATIS are two popular choices in the Java middle-tier space.
Also, because of this:
Fallacies of Distributed Computing
You do not do synchronous interactions from a Flex client to its middle-tier services. Synchronous network operations have become verboten these days and are the hallmark signature of a poorly designed application - as due to reasons enumerated at the above link, the app can (and often will) exhibit a very bad user experience.
You instead make async calls to retrieve data, load the data into your client app's model object(s), and proceed to implement operations on the model. With Flex and BlazeDS you can also have the middle-tier push data to the client and update the client's model objects asynchronously. (Data binding is one way to respond to data being updated in an event driven manner.)
All this probably seems very far afield from the nature of inquiry in your posting - but your posting indicates you're off on an entirely incorrect footing as to how to understand client-side technologies that have asynchronous and event-driven programming baked into their fundamental architecture. These RIA client technologies are designed this way completely on purpose. So you will need to learn their mode of thinking if you want to have a good and productive experience using them.
I go into this in more detail, and with a Flex perspective, in this article:
Flex Async I/O vs Java and C# Explicit Threading
In my direct experience with Flex, I think this discussion is getting too complicated.
Your conceptual OO view is no different between sync and asynch. The only difference is that you use event handlers to deal with the host conversation in the DAL, rather than something returned from a method call. And that often happens entirely on the host side, and has nothing to do with Flex or Silverlight. (If you are using AIR for a workstation app, then it might be in client code, but the same applies. As well if you are using prolonged AJAX. Silverlight, of course, has no AIR equivalent.)
I've been able to design everything I need without any other changes required to accomodate asynch.
Flex has a single-threaded model. If you make a synchronous call to the web server, you'd block the entire GUI of the application. The user would have a frozen application until the call completes (or times out on a network error condition, etc.).
Of course real RIA programs aren't written that way. Their GUI remains accessible and responsive to the user via use of async calls. It also makes it possible to have real progress indicators that offer cancel buttons and such if the nature of the interaction warrants such.
Old, bad user experience web 1.0 applications exhibited the synchronous behaviour in their interactions with the web tier.
As my linked article points out, the async single-threaded model coupled with ActionScript3 closures is a good thing because it's a much simpler programming model than the alternative - writing multi-thread apps. Multi-threading was the approach of writing client-server Java Swing or C# .NET WinForm applications in order to achieve a similarly responsive, fluid-at-all-times user experience in the GUI.
Here's another article that delves into this whole subject matter of asynchronous, messaging/event-driven distributed app architecture:
Building Effective Enterprise Distributed Software Systems
data-driven communication vs behavior-driven communication
Silverlight is a client technology and the Object - Relational mapping happens completely in the server. So you have to forgot about the ORM in Silverlight.
Following your example what you have to do is to create a webservice (SOAP, REST...) that can give your silverlight client the complete "Order" object.
Once you have the object you can work with it with no communication with the server in a normal - synchronous way.
Speaking about Silverlight, you should definitely check RIA services.
Simply, it brings the DataContext from the server to the client from where you can asynchronously query it (there is no need to write WCF services by hand, it's all done by RIA).
C# 5
async / await construct will almost exactly what I want..
watch presentation by anders hejlsberg