Before stating the problem I want to say that I've read all the posts that suggest that what I'm doing is a bad idea and I AGREE WITH YOU 100% but, our customer insists that he wants the id on the URL to be encrypted so we don't have much choice.
The application is ASP .Net MVC 2 and we are using the basic default route of
"{controller}/{action}/{id}" in which the id is encrypted.
The code that returns the encrypted id is as follows:
return HttpUtility.UrlEncode(Encryptor.Encrypt(inputText));
The Encrypt method is using the System.Security.Cryptography.RijndaelManaged class and we get something like:
http://localhost:3396/MyController/MyAction/%253fval%253dWrikkm9UeEmHdsaMJyjgzA%253d%253d
Now when I click on the link I always get a blank page saying:
Server Error in '/' Application.
HTTP Error 400 - Bad Request.
I guess this error is being sent by IIS since the request never reaches the controller.
Any help will be very much appreciated.
Perhaps your customer doesn't want people "guessing" incremental or string IDs in the URL, which is how a lot of insecure web applications get hacked (E.g. Sony) right? It's a slightly-uninformed demand, but well intentioned. I understand your pain.
Would your customer know the difference between a hashed and encrypted ID? Maybe your life could be simpler if you just used salted+hashed IDs, which adds just as much obfuscation (not security!) to the URL, minus the need to URLEncode the encrypted value.
Ideally, you could get this "encrypted ID" requirement punted in favor of a combination of SSL, an authentication system with page level rights-enforcement, and solid audit trail logging. This is standard web application security stuff.
Related
Recently I have attended a training in mvc. The trainer said that - As per the security concerns we have to use HttpPost instead of HttpGet. Always use HttpPost.
Can anyone explain - what is the security issue when we use HttpGet?
When transmitting data over secure connection (https) body of the post request is encrypted and practically undreadable, you can only see address where data is going but not the data itself. Get on the other hand has no body and data has to be transmitted in either query string or as a path parameter. While it is true that query string does get encrypted as well, due to request logging on the server and browser it is possible to get hold of that data.
Anyone can insert image on public forum or stackoverflow with link to your web-site. Then happens next:
Browser looks at url in image tag
Browser find cookies corresponding to domain in url
Browser sends request to url with cookies of user
Your server performs action
Browser tries to parse response as image and fails
Browser renders error instead of image
But if you mark your action as Http Post only then this scenario isn't applicable for 90% of sites. But you should also consider that if hacker can create a form on other web-site then he still can make browser to perform request. So you need CSRF. Well, browsers made a lot to prevent cross-site requests, but it's still possible in some scenarios.
I have a problem authenticating my user against Active Directory. I am trying to authenticate my user via PrincipalContext.
My issue is that when user password contains non-ASCII character validation fails even with the correct credentials. But I have this problem only on my prod environment. It works just fine on UAT and development environments.
How can I resolve this issue? Is there any setting for AD has anything to do with this?
try to change the password encoding to UTF-8
It is a shot in the dark, but hear me out. This is why I asked if this was a web project. I had a similar problem with identical symptoms. A user came to me saying he couldn't login in my website. Turns out he had "special" characters in his password. It didn't make sense, but after disabling custom errors I realized the error was due to ASP.NET Request Validation: http://msdn.microsoft.com/en-us/library/hh882339%28v=vs.100%29.aspx
Request validation is a feature in ASP.NET that examines an HTTP
request and determines whether it contains potentially dangerous
content. In this context, potentially dangerous content is any HTML
markup or JavaScript code in the body, header, query string, or
cookies of the request. ASP.NET performs this check because markup or
code found in the URL query string, cookies, or posted form values
might have been added to the request for malicious purposes.
Pretty much everything that looked like a tag got flagged and runtime threw an exception way before my code had a chance to validate user's password.
Hope this helps!
So I have created a custom token, based mostly from the MSDN example (http://msdn.microsoft.com/en-us/library/ms731872.aspx) but I can't seem to get it to work. I always get this error " security token with the 'Basic' attachment mode must be signed." in the logs. I have been over the code base several times and
A) obviously it compiles and runs
B) I can't see where the issue is.
The log message isn't all that helpful. I thought it might be something with the cert but I have beat that to death and created a couple different certs (one using server name set to localhost etc...).
A Google search for this turns up almost nothing.
Anyone got a clue what this is, or just tell me where I can maybe look? Like I said - I have been through this code many times, I see the authorization policy get created and all that good stuff, I can see the certificate is set, I just don't know where else to look, I really don't have any code to post, there are so many classes you have to implement. If someone has an idea of what maybe I can look at I will be happy to post that particular class / code snippet.
Thanks
See here: http://social.msdn.microsoft.com/forums/en-us/wcf/thread/F822CCB9-A8A1-474F-87AF-E5CD9EC34494
... wasn't copying the "id" property of the security token correctly.
This was causing a new ID to get created for the security token on the server, which no longer matched the security signature data, and so the message would be rejected.
In your implementation of your custom WSSecurityTokenSerializer to serialize your security token, you probably aren't copying the Id property of the token. The ID needs to match from the client to the server.
A common mistake (one that I'm sure I've made too) is to just id = Guid.NewGuid().ToString() in the constructor. That is fine for its initial creation on the clinet, but when it deserializes on the server, it needs to use the same ID from the client, not a new guid again.
I am developing an application in which I am displaying products in a grid. In the grid there is a column which have a disable/enable icon and on click of that icon I am firing a request through AJAX to my page manageProduct.aspx for enabling/disabling that particular product.
In my ajax request I am passing productID as parameter, so the final ajax query is as
http://example.com/manageProduct.aspx?id=234
Now, if someone (professional hacker or web developer) can get this URL (which is easy to get from my javascript files), then he can make a script which will run as a loop and will disable all my products.
So, I want to know that is there any mechanism, technique or method using which if someone tries to execute that page directly then, it will return an error (a proper message "You're not authorized or something") else if the page is executed from the desired page, like where I am displaying product list, then it will ecxecute properly.
Basically I wnat to secure my AJAX requests, so taht no one can directly execute them.
In PHP:
In php my colleague secure this PHP pages by checking the refrer of the page. as below:
$back_link = $_SERVER['HTTP_REFERER'];
if ($back_link =='')
{
echo 'You are not authorized to execute this page';
}
else
{
//coding
}
Please tell me how to the same or any other different but secure techique in ASP.NET (C#), I am using jQUERY in my app for making ajax requests.
Thanks
Forget about using the referer - it is trivial to forge. There is no way to reliably tell if a request is being made directly or as a response to something else.
If you want to stop unauthorised people from having an effect on the system by requesting a URL, then you need something smarter then that to determine their authorisation level (probably a password system implemented with HTTP Basic Auth or Cookies).
Whatever you do, don't rely on http headers like 'HTTP_REFERER', as they can be easily spoofed.
You need to check in your service that your user is logged in. Writing a good secure login system isn't easy either but that is what you need to do, or use the built in "forms authentication".
Also, do not use sequential product id's, use uniqueidentifiers, you can still have an integer product id for display but for all other uses like the one you describe you will want to use the product uniqueidentifier/guid.
One of our application will be run in an iframe, inside salesforce and I'm having troubles with accessing the referer. They'd like us to do some referer checks, to make sure the request is coming from salesforce and we've been given the IP addresses to check against.
My problem is that anytime I try to access the referer through either of the following two methods:
HttpContext.Current.Request.ServerVariables["HTTP_REFERER"]
HttpContext.Current.Request.UrlReferrer
it returns me null.
Any ideas how could I get hold of the referer?
PS: I'm aware that you can spoof the referer, but it's part of the requirement.
If I understand the question correctly you have client sites that refer to your site by embedding IFrames in their webpages the point to your site. You wish to "ensure" that the requests are coming from host page which itself is part of a designated set of sites. The set of designated sites is described by a set of IP addresses. Does that cover it?
Tricky. First off lets assume you've got a referer. You will need to aquire the host name from it (easy enough using the Uri type). Then you need to resolve the IP address for the host name using DNS (again not too difficult with .NET framework).
Of course you need to get a referer and that is the trickiest bit. Browsers do not always place a referer header in the request. This is especially true when the referee address is not in the same domain as the referer, which is the case here. IOW, this is a showstopper.
A better approach to solving this problem (and is not prone to spoofing) is to use some hash based authentication. Doesn't have to be too sophisticated (if the original requirements felt the referer testing was sufficient anyway).
A referrer is only there if the page was requested through a link. When a page is opened say from the address bar in a browser by typing in the address directly (or in your case y setting the src. of the IFRAME), the referrer will be empty.