In the latest Asp.Net December 2013 Security updates Microsoft released a patch for ASP.Net - 'Insecure ASP.NET Web Forms (.aspx) configuration could allow remote code execution'. Related KB is 2905247
As I know ViewStateMac just used to be sure that this ViewState was generated by server, and not an attacker. But in security updates article they say:
If a web developer sets EnableViewStateMac=false for any page in his
site, an attacker could leverage this to upload and invoke arbitrary
executable code within the context of the web service account. This is
an example of a remote code execution (RCE) attack.
For example if I disable EnableViewStateMac for some aspx page, how it allows attacker to execute malicious code in context of my web application? As I understand in the worst case an attacker can spoof ViewState for some fake data\events\validation. But it will affect just this page. And I can't upload any malicious C# code via ViewState that will be executed. What are they mean by RCE attack in that case?
I can't find any further details of this vulnerability, so my answer only speculates to a possible attack vector.
The MAC is a signature of the ViewState value, and with EnableViewStateMac=true ASP.NET will check whether the MAC signature actually signs the ViewState value as authentic. This means that the ViewState value sent from the client in the __VIEWSTATE hidden field has been verified to come from the server.
Now imagine that the code processing the ViewState value is vulnerable to say object deserialisation. The Microsoft advisory states:
An unauthenticated attacker could send specially crafted HTTP content to the targeted server, potentially allowing the attacker to run code on the server in the context of the service account running on the ASP.NET site.
With EnableViewStateMac=true this vulnerability cannot be exploited because the MAC is validated before the ViewState value is processed. Any value that has not come from the server will be met with a Validation of viewstate MAC failed exception message.
However, with EnableViewStateMac=false the whole ViewState value could be manipulated by an attacker to exploit the buffer overflow/escape attack with privilege escalation and execute arbitrary code that is injected as a payload into the __VIEWSTATE field.
So in summary, as the ViewState value is no longer being validated it opens up the field to attack by this unpublicised attack vector.
By itself, it doesn't necessarily allow an attacker to run code, but if you act upon some input expecting it to be valid -- hidden field with values or something similar, then it could be the key they need.
Related
I know how anti-forgery token in ASP.NET MVC works.But still not clear about few scenarios. One I mentioned below.
submit a post request with below information
cookie token(antiforgerytoken)
form data(first name & last name)
form input hidden token(antiforgerytoken)
Before reaching server a hacker modified form data(first name & last name) leaving token info unchanged.
In this scenario, how we can make sure the data submitted securely reached server without any modification
Actually this question is asked by an interviewer. I discussed with my colleagues and I searched in Google too. Since I couldn't find a clarity on this I thought to ask here.
I am not sure if this is a valid question.If yes,any help would be appreciated
Multiple things are mixed here. The confusion is around the purpose of different protections, so let me try and get that straight.
CSRF, and antiforgerytoken
The basic threat is the following. A victim user is logged on to the victim website victim.com. Meanwhile (say in another browser tab) he visits a malicious website malicious.com that wants to exploit CSRF in victim.com. For that, malicious.com has the user post the required parameters to victim.com to call a certain function which obviously victim user did not want to perform. This is the base case of CSRF, exploiting an existing user session, malicious.com performed something on victim.com via a victim user.
This is prevented, if for example antiforgerytoken is used, because malicious.com will not be able to send the right token to victim.com, so the request will be denied.
Note that this has nothing to do with legitimate request content.
Integrity of requests
A different problem is making sure the request is received as sent, ie. data is the same. This is usually achieved by using HTTPS, which provides message integrity and encryption (among others). So if HTTPS is used, such change of data in transit is not possible.
Of course if the attacker controls either the client or the server (more precisely, the TLS endpoint, which is not always the server), ie. anything outside the TLS channel, then the attacker can modify data. But that would mean having control over the client. For example you can do this if you run a local proxy (Fiddler, Burp, ZAP Proxy, etc.) on your client - you can then change any data in the request, that's how penetration testers work. However, an attacker not having this level of control would not be able to do this.
Without HTTPS, request (and btw also response) integrity and encryption are problems that are hard to solve. The solution is HTTPS. :)
This question already has an answer here:
how AntiForgeryToken() works in MVC and how to retrieve value at server action method from AntiForgeryToken?
(1 answer)
Closed 7 years ago.
I'm a relatively new developer working on a C# MVC app, and serving different views to different people depending on what fields they should be able to see. That is, user 1 might see (and be able to enter data into) fields A, B, and C, whereas user 2 may only see field A.
My plan at the moment is to post the form back to a single action in my controller, but I was trying to figure out whether or not I need to protect against the possibility of user 1 modifying the form when (s)he gets it, adding fields B and C in the browser, and then sending it back to the server, in an effort to set values in the database that (s)he shouldn't have access to.
I'm told by someone else in the area that the AntiForgeryToken should protect against this type of attack, but my research implies that it only protects against a cross-site forgery attack, and I don't think this falls into that category. My question is this: Does the AntiForgeryToken protect against this situation? Or do I need to continue with the idea of "don't trust what the user sends you" and explicitly ignore those fields that the user doesn't have rights to use?
You are absolutely right that this is a problem. All the anti-forgery token does is to ensure the form is generated by your application, as opposed to being handcrafted. However, that doesn't mean it can't be tampered with afterwards.
As an example, say you have 2 users, who both have accounts with your application: GoodUser and NaughtyUser. They both use your application to request a specific form, that allows them to do something on the site (e.g. edit an auction). The difference between them is that GoodUser is only interested in editing an auction, but, as the 2 users are in direct competition with each other, NaughtyUser wants to sabotage GoodUser's auction.
To do that, NaughyUser decides to open a form to edit one of his own auctions. At this point, he has received a valid anti-forgery token in the form. So now NaughtyUser modifies the data on the form, the idea being to intentionally edit GoodUser's auction, and POSTs it to the server. The anti-forgery token on its own will absolutely not protect against that, because the token itself was generated via a legitimate source.
This is a different kind of attack, and something you definitely should be protecting against on the server-side.
It is quit simple. In order to protect our server from illegal requests we allow to submit forms that were made only by our server. It means that once ASP.NET server executes action method and prepare HTML for the client, it would sign your form with a encrypted token. When form submits, this server-generated token will be sent with form's data, and if you mark your action with validateantiforgerytoken attribute, then server will check form for this unique token. If it exists and token generated on this server, validation will be passed.
Request Validation is a powerful mechanism to prevent injecting malicious code via a request to server. This is done on server-side so regardless of the fact that whether any client-side validation has done or not, one can be sure if something unusual is coming then an exception will be thrown automatically.
My question:
While we have "Request Validation" in hand, does it still necessary to sanitize requests?
I'm using Asp.net MVC 5.0
PS:
I'm solely talking in the context of web (not DB or something else) and its potential vulnerabilities (such as XSS).
Yes! There is plenty of perfectly valid input in ASP.NET's eyes that could cause issues in your application if not dealt with correctly.
For example, if somebody passed some data in a request and you weren't correctly parameterizing queries in your data layer then this input:
x'; DROP TABLE users; --
Could result in this query:
SELECT FieldList
FROM Users
WHERE Email = 'x'; DROP TABLE Users; --
Oh noes! You've lost your Users table!
You should always treat user-input as hostile irrespective of request validation. This demonstrates some scenarios whereby request validation wouldn't save your skin.
HTML encoding when you render user-provided input is important... Never render any untrusted input using #Html.Raw and be careful that your HtmlHelpers correctly encode anything coming from a user.
Defence in depth is important. Think of request validation as just one piece of that process.
Here's a link about Xss on MSDN and Request Validation
https://msdn.microsoft.com/en-us/library/vstudio/hh882339%28v=vs.100%29.aspx?f=255&MSPPError=-2147217396
We are using the web security scanner which found out one of my web page has a Bind SQLi. The scanner modified the parameter "news.aspx?id=123" to "news.aspx?i=123' or 1=1--", And the web server responses to the news information for id=1 information currently.
After investigation from development team, they said that there's no injection cannot access to Database which has already blocked by the .NET Built-in API SQL Parameter, and the back-end program will auto return the data of id=1 information to client side.
May I know can it be identified as false positive, or is it better to redirect to generic error pages? Or it is enough and acceptable for current stage?
the back-end program will auto return the data of id=1 information to client side.
IMO, this is a lame behavior for the backend. I'd say the page should detect the error and redirect the user to an error page. Nevertheless, based on that description it is not a valid injection, so if the business can accept that behavior, then it is a false positive.
P.S. While this isn't a SQL injection, it is potentially an information disclosure bug if it's possible to get the page to display the data for id=1 and the user of the page shouldn't have access to that particular record.
So long as your underlying application code is parameterizing the values being sent to SQL (as your developers claim), then you do not need to worry about such warnings.
I developed an application using C# and ASP.NET MCV4. In IIS it is set to use Windows authentication which uses only the Kerberos provider.
I used Burp Suite to make tests against poor cookies randomness at login page.
Selected text in the picture was chosen to test how much variable changes during 20k requests.
Results show that estimated entropy is 0 – so variable doesn't change at all.
What are options are there to increase randomness of selected part of header?
What are general methods to increase randomness of session variables stored in cookies?
As #MartinLiversage, this isn't the cookie at all: it's a header from the [MS-N2HT]: Negotiate and Nego2 HTTP Authentication Protocol, which is being used when server recieved the request to protected object without proper auth data.
As you can see, in your case the schema is Authenticate:Negotiate so no need to worry about some data being exposed:
The initial WWW-Authenticate header does not carry any auth-data when
the header is "WWW-Authenticate:negotiate"; it does carry data when
the header is "WWW-Authenticate:Nego2".
More over, this header is simply base64-string and can be easily decripted:
How do I decode a base64 encoded string?
As for the cookies in general, try to add some salt and use the implemented crypto providers, say, RSA provider or something. The question in given form is too broad to find one solution.