On the web based side of things, C# (and more generally, ASP.NET) is commonly vulnerable to the following (items listed by OWASP Top 10 2013). I realise you were mainly interested in sink functions, of which I cover some, however you did ask how people accidentally make dangerous C# code so hopefully I've provided some insight here.
A1-Injection
SQL Injection
Generating queries by string concatenation.
var sql = "SELECT * FROM UserAccount WHERE Username = '" + username "'";
SqlCommand command = new SqlCommand(sql , connection);
SqlDataReader reader = command.ExecuteReader();
This can often be solved by parameterised queries, but if you are using an IN condition it currently isn't possible without string concatenation.
LDAP Injection
Code such as
searcher.Filter = string.Format("(sAMAccountName={1})", loginName);
can make the application vulnerable. More information here.
OS Command Injection
This code is vulnerable to command injection because the second parameter to Process.Start can have extra commands passed to it using the & character to batch multiple commands
string strCmdText= @"/C dir c:\files\" + Request.QueryString["dir"];
ProcessStartInfo info = new ProcessStartInfo("CMD.exe", strCmdText);
Process.Start(info);
e.g. foldername && ipconfig
A2-Broken Authentication and Session Management
Sign Out
The default Forms Authentication SignOut method does not update anything server side, allowing a captured auth token to be continued to be used.
Calling the SignOut method only removes the forms authentication cookie. The Web server does not store valid and expired authentication tickets for later comparison. This makes your site vulnerable to a replay attack if a malicious user obtains a valid forms authentication cookie.
Using Session State for Authentication
A session fixation vulnerability could be present if a user has used session state for authentication.
A3-Cross-Site Scripting (XSS)
Response.Write (and the shortcut <%= =>) are vulnerable by default, unless the developer has remembered to HTML encode the output. The more recent shortcut <%: HTML encodes by default, although some developers may use this to insert values into JavaScript where they can still be escaped by an attacker. Even using the modern Razor engine it is difficult to get this right:
var name = '@Html.Raw(HttpUtility.JavaScriptStringEncode(Model.Name))';
ASP.NET by default enables Request Validation, which will block any input from cookies, the query string and from POST data that could potentially be malicious (e.g. HTML tags). This appears to cope well with input coming through the particular app, but if there is content in the database that is inserted from other sources like from an app written using other technologies, then it is possible that malicious script code could still be output. Another weakness is where data is inserted within an attribute value. e.g.
<%
alt = Request.QueryString["alt"];
%>
<img src="http://example.com/foo.jpg" alt="<%=alt %>" />
This can be exploited without triggering Request Validation:
If alt is
" onload="alert('xss')
then this renders
<img src="http://example.com/foo.jpg" alt="" onload="alert('xss')" />
In old versions of .NET it was a bit of a mine-field for a developer to ensure that their output was correctly encoded using some of the default web controls.
Unfortunately, the data-binding syntax doesn’t yet contain a built-in encoding syntax; it’s coming in the next version of ASP.NET
e.g. not vulnerable:
<asp:Repeater ID="Repeater1" runat="server">
<ItemTemplate>
<asp:TextBox ID="txtYourField" Text='<%# Bind("YourField") %>'
runat="server"></asp:TextBox>
</ItemTemplate>
</asp:Repeater>
vulnerable:
<asp:Repeater ID="Repeater2" runat="server">
<ItemTemplate>
<%# Eval("YourField") %>
</ItemTemplate>
</asp:Repeater>
A4-Insecure Direct Object References
MVC model binding can allow parameters added to POST data to be mapped onto the a data model. This can happen unintentionally as the developer hasn't realised that a malicious user may amend parameters in this way. The Bind attribute can be used to prevent this.
A5-Security Misconfiguration
There are many configuration options that can weaken the security of an application. For example setting customErrors to On or enabling trace.
Scanners such as ASafaWeb can check for this common misconfigurations.
A6-Sensitive Data Exposure
Default Hashing
The default password hashing methods in ASP.NET are sometimes not the best.
A7-Missing Function Level Access Control
Failure to Restrict URL Access
In integrated pipeline mode .NET can see every request and handles can authorise each request, even to non .NET resources (e.g. .js and images). However, if the application i running in classic mode, .NET only sees requests to files such as .aspx so other files may be accidentally unsecured. See this answer for more detail on the differences.
e.g. www.example.com/images/private_photograph_user1.jpg is more likely to be vulnerable in an application that runs in classic mode, although there are workarounds.
A8-Cross-Site Request Forgery (CSRF)
Although the legacy web forms applications are usually more secure against CSRF due to requiring the attacker to forge the View State and Event Validation values, newer MVC applications could be vulnerable unless the developer has manually implemented anti forgery tokens. Note I am not saying that web forms is not vulnerable, just that it is more difficult that simply passing on a few basic parameters - there are fixes though, such as integrating the user key into the View State value.
When the EnableEventValidation property is set to true, ASP.NET validates that a control event originated from the user interface that was rendered by that control. A control registers its events during rendering and then validates the events during postback or callback handling. For example, if a list control includes options numbered 1, 2, or 3 when the page is rendered, and if a postback request is received specifying option number 4, ASP.NET raises an exception. All event-driven controls in ASP.NET use this feature by default.
[EnableEventValidation] feature reduces the risk of unauthorized or malicious postback requests and callbacks. It is strongly recommended that you do not disable event validation.
A10-Unvalidated - Redirects and Forwards
Adding code such as
Response.Redirect(Request.QueryString["Url"]);
will make your site vulnerable. The attack could be initiated by sending a phishing email to a user containing a link. If the user is vigilant they may have double checked the domain of the URL before clicking. However, as the domain will match your domain which the user trusts, they will click the link unaware that the page will redirect the user to the attacker's domain.
Validation should take place on Url to ensure that it is either a relative, allowed URL or an absolute URL to one of your own allowed domains and pages. You may want to check someone isn't redirecting your users to /Logout.aspx for example. Although there may be nothing stopping an attacker from directly linking to http://www.example.com/Logout.aspx, they could use the redirect to hide the URL so it is harder for a user to understand which page is being accessed (http://www.example.com/Redirect.aspx?Url=%2f%4c%6f%67%6f%75%74%2e%61%73%70%78).
Others
The other OWASP categories are:
- A9-Using Components with Known Vulnerabilities
of which I can't think of any to mind that are specific to C#/ASP.NET. I'll update my answer if I think of any (if you think they are relevant to your question).
