I am wondering if there's a good solution for preventing automated form submissions / POST attacks.
Would it be possible to add a form field with a token generated server side that would be unique for each form displayed on the site, but with a way to check if this token was indeed generated by my app and not by user, without having to save all tokens to a database?
IMO if app can know that data comes from a form generated by the app (meaning that it used logic only known to the app), than it would go on to process form.
Any suggesting for such an algorithm?
EDIT: In other words, can I generate a string that:
1) when I receive back, I can recognize as string that I generated,
2) know that it's been used only once,
3) would take user too many attempts to generate such string on the client side,
4) this string does not have to be persisted by the application
You'll probably be interested in Hashcash. I tried to cheat on a blog by multiple voting some comment, but I gave up when I saw that this method is a bit complicated for humans to generate that values.
Related
The client opens a website through a non-web app and thus gives an ID and a unique security code through query strings. So the url looks smth like this: .../Default.aspx?uI=21&sc=b2r#67!kl
For different clients, the website has different content. The users are not more than 10 (considering that 1 client is 1 company that has many employees(users) and for all users of 1 company the security code is the same). So 10 users from the same company will have different IDs (uI) but the same security code (sc) and so on for the different companies.
So is there point in using Sessions or it is sufficient to use just the query string values for distinguishing the users? Why/why not?
Suggestion of any other, better way of implementation is welcome.
I agree that having the URL hold information like UserID's and a security code is not a good idea.
Maybe you could make a 'landing page' where you still pass in this information in a query string, on that page set 2 session variables one for UserID and the other security code. Redirect to the default page without the query strings. Then anytime you need to check the variables you can through session, and without having the querystring showing. Just a thought.
IMO, Using QueryString users could manipulate the resulting output using location bar and changing SC or UI. That may produce undesired output while navigating form one page to another.
It seems to me that if you are trying to pass in a unique identifier for a user you might want to look at passing in a secure token in the URL perhaps a GUID that is a unique combination for the User/Security Code. Then on the back end validate this token and then use ASP.NET Membership to handle storing the user's credentials.
See below for more information on membership:
http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx
I am scanning my web application which i have build in Asp.net. Scanner is injecting junk data into the system trying to do blind Sql injection on the system but i am using Sql store procedures with parametrized quires which is escaping the blind sql injection but these junk entries are stored into the system as normal text i am sanitizing the inputs not to take ' and other sql related parameters.Now my question are
1) Are these junk entries any threat to the system?
2) Do i really need to sanitize the input if i am already using paramitrised quires with store procedures?
3) Scanner is not able to enter information into the system if u don't create login sequence is that a good thing?
Any other precautions i should take please let me know
Thanks
As you correctly mentioned, the 'junk' entries in your database are form submissions that Acunetix is submitting when testing for SQL injection, XSS and other vulnerabilities.
To answer your questions specifically:
1) No, this junk data is just an artifact of the scanner submitting forms. You might want to consider applying stricter validation on these forms though -- remember, if a scanner can input a bunch of bogus data, an automated script (or a real user for that matter) can also insert a bunch of bogus data.
Some ideas for better validation could include restricting the kind of input based on what data should be allowed in a particular field. For example, if a user is expected to input a telephone number, then there is no point allowing the user to enter alpha-characters (numbers, spaces, dashes, parenthesis and a plus sign should be enough for a phone number).
Alternatively, you may also consider using a CAPTCHA for some forms. Too many CAPTCHAs may adversely affect the user experience, so be cautious where, when and how often you make use of them.
2) If you are talking about SQL injection, no, you shouldn't need to do anything else. Parameterized queries are the proper way to avoid SQLi. However, be careful of Cross-site Scripting (XSS). Filtering characters like <>'" is not the way to go when dealing with XSS.
In order to deal with XSS, the best approach (most of the time) is to exercise Context-dependent Outbound Encoding, which basically boils-down to -- use the proper encoding based on which XSS context you're in, and encode when data is printed onto the page (i.e. do not encode when saving data to the database, encode when you are writing that data to the page). To read more about this, this is the easiest, and most complete source I've come across -- http://excess-xss.com/#xss-prevention
3) A login sequence is Acunetix's way of authenticating into your application. Without it, the scanner can not scan the internals of your app. So unless you have forms (perhaps on the customer-facing portion of your site) the scanner is not going to be able to insert any data -- Yes, this is generally a good thing :)
In order to construct an entity with quite a lot of information, I need to performe a sequence of forms submitting. Every time I return a view from a controller, I need to pass some id's about the not yet established entity. Right now I inject these pieces of info into hidden fields, and when post back to server, continuing to construct the entity.
This scenario continues for a few times.
I'm very not satisfied with this way of passing sensitive information, and was wonder if there're other more appropriate ways of doing it. I use authorization and authentication, but still worried of some scenarios in which one user could hack these id's, before sending it back to server, and by that, modifying the wrong entity.
Also, seems kind of hard work to pass back and forth the same data. I disqualified the use of sessions, because it reveals a different kind of data disruption threat . (in case of using more than one browser at a time).
How should I perform the mentioned operation?
You can use a secure hash of the data in another hidden field to detect tampering with the values.
Here is an example of how to generate a cryptographically secure hash http://www.bytemycode.com/snippets/snippet/379/
You can secure your data using many approaches, I discussed some of it in this post
http://miroprocessordev.blogspot.com/2012/03/save-aspnet-mvc-application-against.html
http://miroprocessordev.blogspot.com/2012/03/safe-aspnet-mvc-application-against.html
use Cross-site request forgery with token to identify that everytime u send an info it contains same token generated at server side and returned from your html
I'm using ASP.Net but my question is a little more general than that. I'm interested in reading about strategies to prevent users from fooling with their HTML form values and links in an attempt to update records that don't belong to them.
For instance, if my application dealt with used cars and had links to add/remove inventory, which included as part of the URL the userid, what can I do to intercept attempts to munge the link and put someone else's ID in there? In this limited instance I can always run a check at the server to ensure that userid XYZ actually has rights to car ABC, but I was curious what other strategies are out there to keep the clever at bay. (Doing a checksum of the page, perhaps? Not sure.)
Thanks for your input.
The following that you are describing is a vulnerability called "Insecure Direct Object References" And it is recognized by A4 in the The OWASP top 10 for 2010.
what can I do to intercept attempts to
munge the link and put someone else's
ID in there?
There are a few ways that this vulnerability can be addressed. The first is to store the User's primary key in a session variable so you don't have to worry about it being manipulated by an attacker. For all future requests, especially ones that update user information like password, make sure to check this session variable.
Here is an example of the security system i am describing:
"update users set password='new_pass_hash' where user_id='"&Session("user_id")&"'";
Edit:
Another approach is a Hashed Message Authentication Code. This approach is much less secure than using Session as it introduces a new attack pattern of brute force instead of avoiding the problem all togather. An hmac allows you to see if a message has been modified by someone who doesn't have the secret key. The hmac value could be calculated as follows on the server side and then stored as a hidden variable.
hmac_value=hash('secret'&user_name&user_id&todays_date)
The idea is that if the user trys to change his username or userid then the hmac_value will not be valid unless the attacker can obtain the 'secret', which can be brute forced. Again you should avoid this security system at all costs. Although sometimes you don't have a choice (You do have a choice in your example vulnerability).
You want to find out how to use a session.
Sessions on tiztag.
If you keep track of the user session you don't need to keep looking at the URL to find out who is making a request/post.
I'm writing an Asp.Net WebForms app where I am calling an edit page an passing in the data about the record to be edited using query string parameters in the URL.
Like:
http://myapp.path/QuoteItemEdit.aspx?PK=1234&DeviceType=12&Mode=Edit
On a previous page in the app, I have presented the user with a GridView of screened items he can edit based on his account privileges, and I call the edit page with these above parameter list, and the page know what to do. I do NOT do any additional checking on the target page to validate whether the user has access to the passed in PK record value as I planned to rely on the previous page to filter the list down and I would be fine.
However, it is clear the user can now type in a URL to a different PK and get access to edit that record. (Or, he may have access to Mode=View, but not Mode=Edit or Mode=Delete. Basically, I was hoping to avoid validating the record and access rights on the target page.
I have also tested the same workflow using Session variables to store PK, DeviceType, and Mode before calling the target page, and then reading them from Session in the target page. So there are no query string paramaters involved. This would take control away from the user.
So, I'm looking for feedback on these two approaches so that I choose an accepted/standard way of dealing with this, as it seems like a very common app design pattern for CRUD apps.
Agreed, you'll want to validate permissions on the target page, it's the only way to be absolutely sure. When it comes to security, redundancy isn't a bad thing. Secure your database as if you don't trust the business layer, secure your business layer as if you don't trust the UI, and secure the UI as well.
You should always validate before the real execution of the action, especially if passing the parameters by query string. For the second page that does the execution you might not need as much feedback for the user since you do not have to be nice to the user if he tries to cirumvent your security, so error handling should be a lot easier.
Passing the variables per session is acceptable but imho you should still validate the values.
We always use querystrings so records can be bookmarked easily, however always validate in both places, if you write you access control code nicely it should just be a case of re-using the existing code...
I believe the common practice is to do what you're avoiding: On the original page, you need to check to see what the user should have capabilities to do, and display their options appropriately. Then on the actual work page, you need to check the user again to verify they are allowed to be there, with access to that specific task.
From a usability standpoint, this is what the user would want (keeps it simple, allows them to bookmark certain pages, etc), and security on both pages is the only way to do this.
If you really don't want to check access rights on the target page:
You could hash the PK with the UserID and then add the hash value to the query string.
string hash = hashFunction(PK.toString() + UserID.toString());
Then you have to make sure the hash in the queryString equals the hash value calculated before loading the page.
Assuming this is an internal organization Web application.
Session variables can be manipulated as well, although not as easily. Whatever authentication you're using throughout your site, you should definitely use on your target page as well. Otherwise, you'll be open to exposing data you may not want as you have found out.
You could do the following to make your URLs a bit more secure:
-Use Guids for Primary Keys so users cant guess other record ID's
-The Mode couls be implicit: Guid = Edit, no Guid = New
and..
-Server-side validation is the only way to go.