I am using jQuery with ASP.NET in a project. Instead of using ASP.NET Ajax, I am using jquery's ajax functions. Is there any security risk if I do that? I mean, since I am using jquery's ajax calls, no view state information will be passed to the server so that it can verify the page's authenticity (though it saves a lot of bandwidth..).
I would also like to know what is the best/good practice here.
Microsoft has included Jquery in their Visual Studio releases (see: http://weblogs.asp.net/scottgu/archive/2008/09/28/jquery-and-microsoft.aspx)
If there was a big security risk they probably wouldn't have done that ;)
As with al webapplications never trust the input you recieve. It doesn;t matter if you're working with ASP.Net AJAX, Jquery or any other library. Web requests can always be spoofed. Therefor always sanitize the input you recieve and make sure that the user is authenticated (ASP.Net forms authentication uses cookies and not viewstate).
Make sure that you validate all user input. And post basic authentication information to your Web Services (jQuery.ajax has a data parameter), so that no one can use the services without being a part of the system.
Passing along a session GUID and thus providing the Web Service with full authentication, is enough security for most applications (in addition to normal security checks such as input validation). You may specify closer what security level your application needs.
I use the same practice on many case - jQuery ajax on aspx pages
You can check 3 thinks (select 1-2 of them) and be sure that none can create troubles on your site.
Send all the post data encrypted (if you can).
Send hash value with the post data - and check for the correction of the hash (if you can).
Check that the calls is coming from your host on url.
eg, you have a page 'http://www.yourhost.com/askforajax.aspx',
check if the url starting with the 'http://www.yourhost.com/'
The hash I mean here, must be your implimation of hash or crc check or what ever you like you can call it.
here is a real ajax call from my pages
doSomeWork.aspx?plist=36&pslst=1&e=1202638085&er=12585795
The last 2 parametres are check parametres.
Also inside the the ajax page that make the calculations check every parameter for be correct.
I also check some other thinks in some cases, for example if a user press a button that make a change somewhere this user must have cookies enabled, so I check if the users cookie hash is the same.
For the url check
I belive that the Request.ServerVariables["HTTP_REFERER"], can do the work of checking from where the request come from.
HTTP_REFERER Returns a string containing the URL of the page that referred the request to the current page using an tag. If the page is redirected, HTTP_REFERER is empty
Hope this help you.
Related
I'm currently working on an asp.net application which makes use of a user system
and I was curious about how data was actually sent towards the server from the client.
It appears that the information which is being sent can be easily traced because it isn't encrypted into a hashcode or anything. It's plain ordinary text.
I've used an application called "SocketSniff" for reading the data.
The data sent back appears to be stored in the scriptmanager using the element ID and its value.
Do you know any way to avoid the scriptmanager from showing element contents?
I'm guessing it has something to do with the ViewState but this didn't work at all.
I'm not a security specialist but encrypting sent data and the viewstate are two different things.
When you send data over the internet not only the data from your webform is send but, the entire webform is send back to the server. (not using javascript / AJAX) this is only encrypted if you use a certificate. You can easily buy one and it does not have to be expensive. Please note that when you debug the page in Google Chrome (data will appear not to be encrypted) it gets encrypted in the background when you send it.
The viewstate is used for storing data and preventing page forgery. It’s not 100% bulletproof. But if the page is not very interesting for a hacker (the effort often isn’t worth it) I don’t think your building the webapplication for the FBI, CIA or an International Bank so don’t worry about that. When you alter a page “HTML” and add values to elements that can not have a (specific value). Id’s for example. IIS finds a forgery. IIS send a page with Id 123 and get a forged page back with Id 456 in a specific element. Withoud a vieustate this could lead to a CRUD (Create, Retrieve, Update or Delete) operation. Now IIS sees the forgery and gives an error to the user.
Hope it helps.
Why do we need both client side and server side validation ? i have read that both are necessary for security reasons.. so if client side validation can be bypass then why not use only server side..what is the use of using client side..
It is important for users with slow/restricted/limited internet connection to avoid unnecessary request to the server (e.g. request to submit a form containing invalid data, which will eventually get rejected by the server). The waiting time for the response may become a reason for a user to leave your web page, and then talk bad about your web site to friends and relatives, or even to whoever.
We always want to make all users happy, don't we (even though sometimes we feel that they are the enemy)
Client side validation helps the user to correct the errors without a full postback with all error messages in it. It enhances efficiency, but its just a convenience and can obviously be bypassed.
it's not good practice postback for every validation so you will need to put client side validation to validate fields which are mandatory so you should put client side validation also
About Server side validation, you cant realy compltetly on client side in case browser javascript disabled it is better to be validated at server side.
With client-side rendering, your initial request loads the page layout, CSS and JavaScript. It's all common except that some or all of the content isn't included. Instead, the JavaScript makes another request, gets a response (likely in JSON), and generates the appropriate HTML (likely using a templating library).For subsequent updates to the page, the client-side rendering approach repeats the steps it used to get the initial content. Namely, JavaScript is used to get some JSON data and templating is used to create the HTML.
Updates using server-side rendering is where a lot of developers start going off the deep end. They actually think page refresh
Both client-side and server-side are needed for many reasons. i am writing few points that will explain why it is necessary
for every from validation a request sent from web browser to the web server. so it is a unnecessary overhead to the server for checking every control to validate. suppose 1,00,000 people sending the same request to the server. For every request and response it will take some time(may be in nano seconds) which is really unnecessary. so it is recommended to use client-side validation.
For security reason we must use the server-side validation. As a programmer it is responsible to stop the bad data coming to our application. suppose in browser someone intentionally or by unknowingly disable the JavaScript and trying to insert the data. if server-side validation is not present there bad data can come to our application. Data may be some wrong information or it can be a self executed program also which is really harmful for our application.
so it is recommended to use both client-side and server-side validation for a better standard application.
You don't need client side, but it's much more convenient for the user if a post-back isn't necessary. If you don't care about the UX, you can make all of your validators server-side only and your data and operations will be protected.
I've been trying (unsuccessfully, I might add) to scrape a website created with the Microsoft stack (ASP.NET, C#, IIS) using Python and urllib/urllib2. I'm also using cookielib to manage cookies. After spending a long time profiling the website in Chrome and examining the headers, I've been unable to come up with a working solution to log in. Currently, in an attempt to get it to work at the most basic level, I've hard-coded the encoded URL string with all of the appropriate form data (even View State, etc..). I'm also passing valid headers.
The response that I'm currently receiving reads:
29|pageRedirect||/?aspxerrorpath=/default.aspx|
I'm not sure how to interpret the above. Also, I've looked pretty extensively at the client-side code used in processing the login fields.
Here's how it works: You enter your username/pass and hit a 'Login' button. Pressing the Enter key also simulates this button press. The input fields aren't in a form. Instead, there's a few onClick events on said Login button (most of which are just for aesthetics), but one in question handles validation. It does some rudimentary checks before sending it off to the server-side. Based on the web resources, it definitely appears to be using .NET AJAX.
When logging into this website normally, you request the domian as a POST with form-data of your username and password, among other things. Then, there is some sort of URL rewrite or redirect that takes you to a content page of url.com/twitter. When attempting to access url.com/twitter directly, it redirects you to the main page.
I should note that I've decided to leave the URL in question out. I'm not doing anything malicious, just automating a very monotonous check once every reasonable increment of time (I'm familiar with compassionate screen scraping). However, it would be trivial to associate my StackOverflow account with that account in the event that it didn't make the domain owners happy.
My question is: I've been able to successfully log in and automate services in the past, none of which were .NET-based. Is there anything different that I should be doing, or maybe something I'm leaving out?
For anyone else that might be in a similar predicament in the future:
I'd just like to note that I've had a lot of success with a Greasemonkey user script in Chrome to do all of my scraping and automation. I found it to be a lot easier than Python + urllib2 (at least for this particular case). The user scripts are written in 100% Javascript.
When scraping a web application, I use either:
1) WireShark ... or...
2) A logging proxy server (that logs headers as well as payload)
I then compare what the real application does (in this case, how your browser interacts with the site) with the scraper's logs. Working through the differences will bring you to a working solution.
I need to share session in order to pass data from asp page to aspx. The solutions I've found:
• Pass data through hidden form (link)
• Pass data through database (link)
I've tried method with form and it worked fine (after some modification). Now I'm trying method with database. First method is easier imho, so I wonder if the second method is more secure (and preferable) than the first one?
And what potential problems exist with these methods?
The first solution is definitely less secure since you're sending session data to the client and then receiving it back. That means that it's possible for someone on the client side to modify the data they post back to your page. This removes one of the best things about sessions, that only the programmer controls what's in them. In a way, the first method is similar to using cookies. As for the second method, it may be more difficult but I would definitely recommend it over the first.
If the session is encrypted I think you will fine. ASP.NET has the option of storing the session in a database and URL querystring to get around users not having cookies enabled. Your solutions sound similiar.
Microsoft outlines a method to share session state between ASP classic and ASP.NET using SQL Server to store the session here: http://msdn.microsoft.com/en-us/library/aa479313.aspx
Is there a "clever" way of stopping direct page calls in ASP.NET? (Page functionality, not the page itself)
By clever, I mean not having to add in hashes between pages to stop AJAX pages being called directly. In a nutshell, this is stopping users from accessing the Ajax pages without it coming from one of your websites pages in a legitimate way. I understand that nothing is impossible to break, I am simply interested in seeing what other interesting methods there are.
If not, is there any way that one could do it without using sessions/cookies?
Have a look at this question: Differentiating Between an AJAX Call / Browser Request
The best answer from the above question is to check for a requested-by or custom header.
Ultimately, your web server is receiving requests (including headers) of what the client sends you - all data that can be spoofed. If a user is determined, then any request can look like an AJAX request.
I can't think of an elegant method to prevent this (there are inelegant and probably non-perfect methods whereby you provide a hash of some sort of request counter between ajax and non-ajax requests).
Can I ask why your application is so sensitive to "ajax" pages being called directly? Could you design around this?
You can check the Request headers to see if the call is initiated by AJAX Usually, you should find that x-requested-with has the value XMLHttpRequest. Or in the case of ASP.NET AJAX, check to see if ScriptMAnager.IsInAsyncPostBack == true. However, I'm not sure about preventing the request in the first place.
Have you looked into header authentication? If you only want your app to be able to make ajax calls to certain pages, you can require authentication for those pages...not sure if that helps you or not?
Basic Access Authentication
or the more secure
Digest Access Authentication
Another option would be to append some sort of identifier to your URL query string in your application before requesting the page, and have some sort of authentication method on the server side.
I don't think there is a way to do it without using a session. Even if you use an Http header, it is trivial for someone to create a request with the exact same headers.
Using session with ASP.NET Ajax requests is easy. You may run into some problems, like session expiration, but you should be able to find a solution.
With sessions you will be able to guarantee that only logged-in users can access the Ajax services. When servicing an Ajax request simply test that there is a valid session associated with it. Of course a logged-in user will be able to access the service directly. There is nothing you can do to avoid this.
If you are concerned that a logged-in user may try to contact the service directly in order to steal data, you can add a time limit to the service. For example do not allow the users to access the service more often than one minute at a time (or whatever rate else is needed for the application to work properly).
See what Google and Amazon are doing for their web services. They allow you to contact them directly (even providing APIs to do this), but they impose limits on how many requests you can make.
I do this in PHP by declaring a variable in a file that's included everywhere, and then check if that variable is set in the ajax call file.
This way, you can't directly call the file ever because that variable will never have been defined.
This is the "non-trivial" way, hence it's not too elegant.
The only real idea I can think of is to keep track of every link. (as in everything does a postback and then a response.redirect). In this way you could keep a static List<> or something of IP addresses(and possible browser ID and such) that say which pages are allowed to be accessed at the moment from that visitor.. along with a time out for them and such to keep them from going straight to a page 3 days from now.
I recommend rethinking your design to be sure that this is really needed though. And also note IPs and such can be spoofed.
Also if you follow this route be sure to read up about when static variables get disposed and such. You wouldn't want one of those annoying "your session has expired" messages when they have been using the site for 10 minutes.