Found this code for preventing some basic MySql injections using HTTPModules
public class SampleSqlInjectionScreeningModuleCS : IHttpModule
{
//Defines the set of characters that will be checked.
//You can add to this list, or remove items from this list, as appropriate for your site
public static string[] blackList = {"--",";--",";","/*","*/","##","#",
"char","nchar","varchar","nvarchar",
"alter","begin","cast","create","cursor","declare","delete","drop","end","exec","execute",
"fetch","insert","kill","open",
"select", "sys","sysobjects","syscolumns",
"table","update"};
public void Dispose()
{
//no-op
}
//Tells ASP.NET that there is code to run during BeginRequest
public void Init(HttpApplication app)
{
app.BeginRequest += new EventHandler(app_BeginRequest);
}
//For each incoming request, check the query-string, form and cookie values for suspicious values.
void app_BeginRequest(object sender, EventArgs e)
{
HttpRequest Request = (sender as HttpApplication).Context.Request;
foreach (string key in Request.QueryString)
CheckInput(Request.QueryString[key]);
foreach (string key in Request.Form)
CheckInput(Request.Form[key]);
foreach (string key in Request.Cookies)
CheckInput(Request.Cookies[key].Value);
}
//The utility method that performs the blacklist comparisons
//You can change the error handling, and error redirect location to whatever makes sense for your site.
private void CheckInput(string parameter)
{
for (int i = 0; i < blackList.Length; i++)
{
if ((parameter.IndexOf(blackList[i], StringComparison.OrdinalIgnoreCase) >= 0))
{
//
//Handle the discovery of suspicious Sql characters here
//
HttpContext.Current.Response.Redirect("~/About.aspx"); //generic error page on your site
}
}
}
}
Is it a good code or do you think I need to add more things in the blacklist, or forget this and try another way to prevent injection?
Why perform string inspection when parameterized queries will do that work for you (and more)?
Use Parameters.Add() or Parameters.AddWithValue() on your SQL statements that you're issuing from code.
Blacklist approach to santizing/filtering data is never the best approach to santizing data. (Although it is appropriate in some cases depending on the trade-offs)
A simple explanation exists here: http://www.testingsecurity.com/whitelists_vs_blacklists
A Blacklist is testing a desired input against a list of negative
input's. Basically you would compile a listing of all the negative or
bad conditions, then verify that the input received is not one of the
bad or negative conditions. A Whitelist is testing a desired input
against a list of possible correct input's. To do this you would
compile a list of all the good input values/conditions, then verify
that the input received IS one of this correct conditions.
Which would you think is better? An attacker will use any means
possible to gain access to your web based application. This includes
trying all sorts of negative or bad conditions, various encoding
methods, and appending malicious input data to valid data. Do you
think you can think of every possible bad permutation that could
occur? A Whitelist is the best way to validate input. You will know
exacty what is desired and that there is not any bad types accepted.
Typically the best way to create a whitelist is with the use of
regular expression's. Using regular expressions is a great way to
abstract the whitelisting, instead of manually listing every possible
correct value.
You're better off using the standard, tried-and-true defenses: parameterized queries or parameterized stored procedures.
No it is not good.
It will block valid inputs and in no way protects code that constructs queries from bad/invalid data.
Just construct queries correctly assuming incoming data is bad and you'll be much better off.
No, blacklisting doesn't work to stop SQL injection. See the OWASP page for methods of getting around blacklists. You should just use parameterized queries
Related
So here is the code:
using(var dbContext = contextFactory.GetContext())
{
foreach(item in dbContext.Items)
{
try
{
var result = IRemoteWebService.SomeOperation(item);
}
catch(MyException e)
{
//assume that all possible exceptions are caught
}
}
}
Question: As far as I know the only possible problem in doing this is http call time-outs, which can be different for initial web request and web request made inside using DbContext. What are other possible disadvantages of doing this?
It is considered bad practice because you are mixing responsibilities. Your Database connection stays open while calling the HTTP service.
To make it more concrete: imagine a stall in the HTTP server and a high load on this particular function. In that case you'll have several DB connections open at the same time. This can cause unwanted side affects. For example Record locking (especially when you are also using write actions) or you could even hit your maximum DB-connection count.
A better approach would be to fetch the data first and than call your HTTP service. The code might look more like this:
List<Items> items = null;
using(var dbContext = contextFactory.GetContext())
{
items = dbContext.Items.ToList(); //query all the items
}
//now loop the items
foreach(item in items )
{
try
{
var result = IRemoteWebService.SomeOperation(item);
}
catch(MyException e)
{
//assume that all possible exceptions are caught
}
}
It would be even better if you create sepperate methods, (put them in different classes even), for your data-query and http-call. This way you can reuse the code better and it's easier to maintain, more flexible en better testable.
As for a general note: it's best to keep things like connections (db, http, tcp/ip, filesystem etc.), graphics, locks, etc. open for the shortest time possible. There are of course performance optimization arguments which can argue this statement, but these are seldom valid since code complexity will increase at its cost.
I have a Controller (lets call it Users) and an Action (lets call it AxGetUser) -
I want to pass in an Integer so it looks like:
AxGetUser(int id)
However, if someone passes in a string or ANYTHING else -
I want to be able to capture it and log it as a possible attack attempt.
So I want to know about it.
So if my model is able to make use of the INT I know its a valid integer - but if I get something other than an int - I want to know about it so I can log it and be aware that someone may be trying to manipulate the parameters they are sending to me so that they may attack the system -
What options do I have?
Seems overly protective, but sure you have a lot of options.
By default ASP.NET MVC model binding will pass in a 0 if someone tries to pass in a string. If you want to see if somebody tried to pass in anything at all you can always look at Request.Form or Request.Params. The issue is whether the value was Posted or part of the route.
My point is, you always have access to all the data passed in through the Request object, model binding is just an abstraction around that.
You should be really careful with this. You don't want to A. impact valid attempts in a negative way that prevent users from continuing to use your system and B. create a overly complex system that creates an implementation and maintenance nightmare. I would suggest programming for these attacks as an exception and not the rule. In this case I would build out controllers as you normally would:
public ActionResult AxGetUser(int id)
{
}
Then I would use Elmah to log when exceptions occur in my application.
If you happen to know the attack vectors someone might use, you could build your own custom model binder and throw specific Exceptions that would be logged in Elmah so that you can search for those specific problems.
You have two options:
First Solution: assign a default value for your parameter and if the value is still the default in your code, then voila, you have caught that special case:
void AxGetUser(int id = 0)
{
if( id == 0)
{
//you caught him !!
}
}
Second Solution: accept a string parameter and try to parse it. If the parse succeeds, then everything is fine otherwise you have the special case:
void AxGetUser(string id)
{
if( !int.TryParse(id))
{
//you caught him !!
}
}
I know the title is a little too broad, but I'd like to know how to avoid (if possible) this piece of code I've just coded on a solution of ours.
The problem started when this code resulted in not enough log information:
...
var users = [someRemotingProxy].GetUsers([someCriteria]);
try
{
var user = users.Single();
}
catch (InvalidOperationException)
{
logger.WarnFormat("Either there are no users corresponding to the search or there are multiple users matching the same criteria.");
return;
}
...
We have a business logic in a module of ours that needs there to be a single 'User' that matches some criteria. It turned out that, when problems started showing up, this little 'inconclusive' information was not enough for us to properly know what happened, so I coded this method:
private User GetMappedUser([searchCriteria])
{
var users = [remotingProxy]
.GetUsers([searchCriteria])
.ToList();
switch (users.Count())
{
case 0:
log.Warn("No user exists with [searchCriteria]");
return null;
case 1:
return users.Single();
default:
log.WarnFormat("{0} users [{1}] have been found"
users.Count(),
String.Join(", ", users);
return null;
}
And then called it from the main code like this:
...
var user = GetMappedUser([searchCriteria]);
if (user == null) return;
...
The first odd thing I see there is the switch statement over the .Count() on the list. This seems very strange at first, but somehow ended up being the cleaner solution. I tried to avoid exceptions here because these conditions are quite normal, and I've heard that it is bad to try and use exceptions to control program flow instead of reporting actual errors. The code was throwing the InvalidOperationException from Single before, so this was more of a refactor on that end.
Is there another approach to this seemingly simple problem? It seems to be kind of a Single Responsibility Principle violation, with the logs in between the code and all that, but I fail to see a decent or elegant way out of it. It's even worse in our case because the same steps are repeated twice, once for the 'User' and then for the 'Device', like this:
Get unique user
Get unique device of unique user
For both operations, it is important to us to know exactly what happened, what users/devices were returned in case it was not unique, things like that.
#AntP hit upon the answer I like best. I think the reason you are struggling is that you actually have two problems here. The first is that the code seems to have too much responsibility. Apply this simple test: give this method a simple name that describes everything it does. If your name includes the word "and", it's doing too much. When I apply that test, I might name it "GetUsersByCriteriaAndValidateOnlyOneUserMatches()." So it is doing two things. Split it up into a lookup function that doesn't care how many users are returned, and a separate function that evaluates your business rule regarding "I can handle only one user returned".
You still have your original problem, though, and that is the switch statement seems awkward here. The strategy pattern comes to mind when looking at a switch statement, although pragmatically I'd consider it overkill in this case.
If you want to explore it, though, think about creating a base "UserSearchResponseHandler" class, and three sub classes: NoUsersReturned; MultipleUsersReturned; and OneUserReturned. It would have a factory method that would accept a list of Users and return a UserSearchResponseHandler based on the count of users (encapsulating the logic of the switch inside the factory.) Each handler method would do the right thing: log something appropriate then return null, or return a single user.
The main advantage of the Strategy pattern comes when you have multiple needs for the data it identifies. If you had switch statements buried all over your code that all depended on the count of users found by a search, then it would be very appropriate. The factory can also encapsulate substantially more complex rules, such as "user.count must = 1 AND the user[0].level must = 42 AND it must be a Tuesday in September". You can also get really fancy with a factory and use a registry, allowing for dynamic changes to the logic. Finally, the factory nicely separates the "interpreting" of the business rule from the "handling" of the rule.
But in your case, probably not so much. I'm guessing you likely have only the one occurrence of this rule, it seems pretty static, and it's already appropriately located near the point where you acquired the information it's validating. While I'd still recommend splitting out the search from the response parser, I'd probably just use the switch.
A different way to consider it would be with some Goldilocks tests. If it's truly an error condition, you could even throw:
if (users.count() < 1)
{
throw TooFewUsersReturnedError;
}
if (users.count() > 1)
{
throw TooManyUsersReturnedError;
}
return users[0]; // just right
How about something like this?
public class UserResult
{
public string Warning { get; set; }
public IEnumerable<User> Result { get; set; }
}
public UserResult GetMappedUsers(/* params */) { }
public void Whatever()
{
var users = GetMappedUsers(/* params */);
if (!String.IsNullOrEmpty(users.Warning))
log.Warn(users.Warning);
}
Switch for a List<string> Warnings if required. This treats your GetMappedUsers method more like a service that returns some data and some metadata about the result, which allows you to delegate your logging to the caller - where it belongs - so your data access code can get on with just doing its job.
Although, to be honest, in this scenario I would prefer simply to return a list of user IDs from GetMappedUsers and then use users.Count to evaluate your "cases" in the caller and log as appropriate.
I have various classes for handling form data and querying a database. I need some advice on reducing the amount of code I write from site to site.
The following code is for handling a form posted via ajax to the server. It simply instantiates a Form class, validates the data and processes any errors:
public static string submit(Dictionary<string, string> d){
Form f = new Form("myform");
if (!f.validate(d)){
return f.errors.toJSON();
}
//process form...
}
Is there a way to reduce this down to 1 line as follows:
if (!Form.validate("myform", d)){ return Form.errors.toJSON(); }
Let's break that down into two questions.
1) Can I write the existing logic all in one statement?
The local variable has to be declared in its own statement, but the initializer doesn't have to be there. It's prefectly legal to say:
Form f;
if (!(f=new Form("myform")).validate(d))return f.errors.toJSON();
Why you would want to is beyond me; doing so is ugly, hard to debug, hard to understand, and hard to maintain. But it's perfectly legal.
2) Can I make this instance method into a static method?
Probably not directly. Suppose you had two callers validating stuff on two different threads, both calling the static Form.Validate method, and both producing errors. Now you have a race. One of them is going to win and fill in Form.Errors. And now you have two threads reporting the same set of errors, but the errors are wrong for one of them.
The better way to make this into a static method is to make the whole thing into a static method that has the desired semantics, as in plinth's answer.
Errors errors = Validator.Validate(d);
if (errors != null) return errors.toJSON();
Now the code is very clear, and the implementation of Validate is straightforward. Create a form, call the validator, either return null or the errors.
I would suggest that you don't need advice on reducing the amount of code you write. Rather, get advice on how to make the code read more like the meaning it intends to represent. Sometimes that means writing slightly more code, but that code is clear and easy to understand.
I would move all common validation logic to a superclass.
I think the main problem of your code is not that is long, but that you're repeating that in many places, either if you manage to make it a one-liner, it would not be DRY.
Take a look at the Template Method pattern, it might help here (The abstract class with the validation would be the Template and your specific 'actions' would be the subclasses).
Of course you could write this:
public static string FormValidate(Dictionary<string, string> d)
{
Form f = new Form("myform");
if (!f.validate(d))
return f.errors.ToJSON();
return null;
}
then your submit can be:
public static string submit(Dictionary<string, string> d)
{
if ((string errs = FormValidate(d))!= null) { return errs; }
// process form
}
That cuts down your code and doesn't hurt readability much at all.
If you really, really wanted to, you could store the error text in a thread-local property.
Does C# have a "ThreadLocal" analog (for data members) to the "ThreadStatic" attribute?
When parsing an xml document for its nodes or attributes, if the document is large, I would have a bunch of ifs and else statements.
Obviously, 100+ ifs does not make up maintainable code in the long run.
Rather than doing this, is there another better way? I read on Hanselman's blog about a friend of his who had the same situation and wrote loads of ifs/else if and generally poor code. Hanselman provided some snippets of a more maintainable way but the entire code isn't available so it's a little hard to understand exactly what (the whole picture) is going on. Life after if, else
I am using .NET 3.5 SO I have the full power of extension methods and LINQ available to me. However, I use .NET 2.0 a work so would also appreciate any solutions in v2.0. :)
My code looks very similar to the problem on Hanselman's site:
if (xmlNode.Attributes["a"].Value == "abc"
{
}
else if (xmlNode.Attributes["b"].Value == "xyz"
{
wt = MyEnum.Haze;
}
I could just have a dictionary storing the values I am looking for as keys and perhaps a delegate in the value (or whatever I want to happen on finding a required value), so I could say if (containskey) get delegate and execute it, in pseudocode.
This sort of thing goes on and on. Obviously very naive way of coding. I have the same problem with parsing a text document for values, etc.
Thanks
If you need to map <condition on xml node> to <change of state> there's no way to avoid defining that mapping somewhere. It all depends on how many assumptions you can make about the conditions and what you do under those conditions. I think the dictionary idea is a good one. To offer as much flexibility as possible, I'd start like this:
Dictionary<Predicate<XmlNode>, Action> mappings;
Then start simplifying where you can. For example, are you often just setting wt to a value of MyEnum like in the example? If so, you want something like this:
Func<MyEnum, Action> setWt = val =>
() => wt = val;
And for the presumably common case that you simply check if an attribute has a specific value, you'd want some convenience there too:
Func<string, string, Predicate<XmlNode>> checkAttr = (attr, val) =>
node => node.Attributes[attr] == val;
Now your dictionary can contain items like:
...
{checkAttr("a", "abc"), setWt(MyEnum.Haze)},
...
Which is nice and terse, but also isn't restricted to the simple <attribute, value> to <enum> mapping. OK, so now you have a big dictionary of these condition-action pairs, and you just say:
foreach(DictionaryEntry<Predicate<XmlNode>, Action> mapping in mappings)
{
if (mapping.Key(xmlNode))
{
mapping.Value();
break;
}
}
If you avoid the lambda syntax and the dictionary initializers, you should be able to do that in 2.0.
What you're doing here is executing a list of tests. For each test, if a predicate is true, execute an action. When a test passes, stop processing the list. Right?
A couple of people have suggested using a dictionary, but the problem with using a dictionary is that you don't control the order of the items in it. If you want to perform the tests in a specific order (which, as stated, you do), that's not going to work. So a list seems like the way to go.
Here's a functional way to do this, assuming that the predicates are examining an XmlElement.
Your tests are instances of a class:
class Test
{
string Predicate { get; set; }
Action Verb { get; set; }
Test(string predicate, Action verb)
{
Predicate = predicate;
Verb = verb;
}
bool Execute(XmlElement e)
{
if (e.SelectSingleNode(Predicate) != null)
{
Verb();
return true;
}
return false;
}
}
To populate the list of tests:
List<Test> tests = new List<Test>();
tests.Add(new Test("#foo = 'bar'", Method1));
tests.Add(new Test("#foo = 'baz'", Method2));
tests.Add(new Test("#foo = 'bat'", Method3));
To execute the tests:
foreach (Test t in tests)
{
if (t.Execute()) break;
}
You've eliminated a lot of if/else clutter, but you've replaced it with this:
void Method1()
{
... do something here
}
void Method2()
{
... do something else here
}
If your method naming is good, though, this results in pretty clean code.
To use .NET 2.0, I think you need to add this to the code:
public delegate void Action();
because I think that type was defined in 3.0. I could be wrong.
The link you are referring to spells out one of my favorite approaches - populating a dictionary and using it as a map from your xml attributes to the values you're setting, etc.
Another "trick" I've used is taking an extension on that. If your logic around containing a specific attribute is more than just setting a value, you can make a dictionary of attribute names (or values) to delegates, where the delegate sets your value and optionally performs some logic.
This is nice because it works in .net 2 and .net3/3.5. The delegates can be nicer to setup in .net 3.5, though.
Once you have the map, then you can do a foreach loop on all of your attributes, and just lookup the delegate, if it exists, call it, if it doens't, move on/throw/etc - all up to you.
Well, I would use LINQ in 3.5. However, have you thought about using a typed dataset; is this a possibility or is the schema too loose? You could infer the schema and still reduce a lot of the gobbeldy-gook code. This is one approach.
Depending on the document and your scenario and what you use the if/elses for... if it's for validation of your XML document, validate it against a schema. If it validates, you can assume safely that certain elements are present...
It's a bit hard to tell what you need to do. If it's to set one variable based on an XML attribute then the one line approach Hanselman alluded to is the most elegant.
MyEnum wt = (MyEnum)Enum.Parse(typeof(MyEnum), xmlNode.Attributes["a"].Value, true);
From the brief example you provided it looks like you may need to set the variable based on different XML attributes and if that's the case you may not be able to get around the need for a big if/else block.
If you do have a semblance of structure in the XML you are processing it can sometimes be easier to process an XML node as a DataRow. If your XML is all over the place then this approach isn't much good.
DataSet xmlDerivedSet = new DataSet();
xmlDerivedSet.ReadXml(xmlFilename);
foreach (DataRow row in xmlDerivedSet.Tables[0].Rows)
{
MyClass xmlDerivedClass = new MyClass(row);
}
If you are doing processing for each big node, you might also want to have some specific typed xml reader classes to more cleanly integrate separate it from the actual logic of the application.
Lets say the processing you are doing is for some good amount of customer data you are receiving in Xml. You could define a class like:
public class CustomerXmlReader
{
public class CustomerXmlReader(XmlReader xml){}
public Customer Read()
{ // read the next customer
}
}
This way the rest of the application just keep working with the Customer object, and you avoid mixing it with the Xml processing.
What Scott Hanselman is describing, once you clear away the implementation details, is a straightforward table-driven method. These are discussed in many books, such as Steve McConnell's "Code Complete", chapter 12 (either edition.) Also discussed on Stack Overflow,
here.