Simple Linq Security

Question

I'm trying to find the security flaws within my ASP.NET login page. How would I go about sanitizing the user input so that XSS and SQL injection is not possible? I feel that my Linq queries are secure but I could be wrong. Please let me know if you need any more information.

String username = usernameTxt.Text.toString();

Company check = (from u in context.Company
                                where u.companyadminUserName.Equals(username)
                                select u).FirstOrDefault();

if (check == null)
{        
    return BAD_USER;
}
else
{
    return GOOD_USER;
}

See http://stackoverflow.com/questions/305044/how-can-i-avoid-sql-injection-attacks-in-my-asp-net-application and http://stackoverflow.com/questions/3955658/how-do-you-avoid-xss-vulnerabilities-in-asp-net-mvc — kittykittybangbang, Jun 27 '15 at 00:59
This is Linq (Language Integrated Query), not Lync (An enterprise communications product) — Dai, Jun 27 '15 at 01:15
L2S and L2E use parameterization (which is incredibly easy to check with either a profiler or by manually dumping your query) so you should be perfectly fine. — David L, Jun 27 '15 at 01:48
@DavidL, but that is false sense of security in a way, in the sense that I wouldn't feel comfortable saying "I'm protected against XSS/SQL injection" categorically without handling the issue systematically. If it is an implementation detail left outside of your awareness before the fact then it is a problem right — tacos_tacos_tacos, Jun 27 '15 at 01:55
@tacos_tacos_tacos First, it's worth pointing out that this question doesn't address XSS in any way. Second of all, if you are using the object model api (which the OP is) your queries will be parameterized and string concatenation is not used so yes, you can say that you are protected against injection as long as you are not executing sql commands and/or unsafe stored procedures via entity framework. — David L, Jun 27 '15 at 01:59
He did mention XSS in passing in the question, and again, you are right about LINQ to SQL in the case of Entity Framework,hopefully in all LINQ to SQL impl's, but I just wanted to say this would be a good time to review the issue of input validation in general because whether it's SQL injection or scripting, the real issue is that one either has to implement perfectly safe (or know of perfectly safe) implementations or have common-sense, cross-cutting, fail-safes in place to detect such cases even when you didnt think of it in advance. — tacos_tacos_tacos, Jun 27 '15 at 02:08

tacos_tacos_tacos · Accepted Answer · 2015-06-27T01:53:47.233

Well, this is where it helps to know something about the implementation of LINQ-to-SQL you are using. I would imagine that every implementation would by default escape arguments to the LINQ extension methods, but never hurts to double-check.

In general, you want there to always be a middle-man sitting between the user interface and the service layer. You probably have them all over your apps; validators. They are more obviously-necessary in the case of validating that a number is a number or that a zip code is a zip code, but nowhere are the stakes higher than for validating that all user input is not unescaped. But that's not good enough - that's just the beginning.

What I would recommend is to institute something like what ASP.NET provides at the boundary - to prevent HTML from being inputted into user interface inputs as well - but also at the boundary between your thin controller and thick service, or as its own layer.

In such a design, maybe you can implement an attribute or annotation like InterrogateTheCarrierAttribute on every database input parameter (assuming you have parameterized into functions all of your database calls, and you are not concatenating strings to make queries). And on anything like it: every Powershell call wrapper or sh wrapper or function to access bank accounts and withdraw money, etc. Then, as the objects make their way in one form or another, every time they cross a "validation boundary," they have to be sanitized as if there is no guarantee of sanitation beyond. This is overkill but unless the validation is costly, why not?

Think of this: instead of bad user interface input, what if a text file or a trusted web service becomes compromised instead? If you think about it in terms of "this tier, this tier," you can convince yourself that there is safety where there is not. Microsoft's web server would never send you malformed packets, right? Your logger would never send your database bad SQL, right? But it can happen. So with the "cross-cutting" approach to validation, you always validate at the boundaries, at least on the way in, and possibly on the way out. And by doing so, you make it less likely for a bad assumption to leave your database interface wide open.

Example: take your query. The issue at stake is 1) whether username gets escaped, and 2) whether it is possible for an unescaped username to somehow overcome the fact that LINQ to SQL is a major abstraction and doesn't lend itself immediately to injection.

Now you should know the answers to those, but our system shouldn't require omniscience to be effective. So, I propose implementing a cross-cutting layer for validation, however you want to do it.

Simple Linq Security

1 Answers1