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.
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. :)
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
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.
I'm designing a site using ASPx and IIS, where clients can sign up and then offer services to their clients. For example:
if you go to http://www.mywebsite.com you can sign up for your mywebsite.com account as a business owner. When you sign up, you are given a Site ID (Example: AA1234).
http://www.mywebsite.com/AA1234
What I want to do is always include the Site ID in every url (Inbound and Outbound). The Site ID is stored in a session variable based on the initial incoming request.
Does anyone know of a good way to do this - or a different design that works better than this?
Thanks
Your question is nebulous at best. However...
Wouldn't this be what cookies are used for?
In particular, if your user is authenticated (this is generally achieved in asp.net with an auth cookie), then at the server, you would have tools at your disposal that allow you to recognize the user and provide a different experience according to whatever criteria you choose. Most likely, these details might be stored in a database.
Found the answer in this topic: http://www.tek-tips.com/viewthread.cfm?qid=1149673
The last response from BoulderBum is exactly what I needed.
Using the HTTP module I will take the /AA1234/ URL and point it to /Company/.
On the way out, I replace all instances of /Company/ with the site id again
I have deployed the web application and customer accessing web application publically in between my databse down then I want show the custom message to the user. In my web application 50 pages, and I want to handle message commonly for all pages. Please help how to do this.
You can configure a section in web.config that tells ASP.NET/IIS to redirect users to a set of static or dynamic pages in case of common errors.
Check out this article - http://www.asp.net/hosting/tutorials/displaying-a-custom-error-page-cs
The scenario is pretty similar - something goes wrong with the SQL DB call and you dont want to display an ugly error.
Make sure to include some sort of logging somewhere so that you know these errors are happing, however. One plus side of ugly error messages are that you'll hear about them right away ;)