We are talking about Classic ASP and NOT ASP.NET!
Lets start from top. We are using ISAPI_Rewrite and we would like to dynamically offer our customers to control rewriting of urls (giving them httpd.ini is not an option). We were thinking that all unknown url requests (we define this in httpd.ini) are controlled by one asp file which creates a GET request to select url (customers creates key -> value table). Now, we can make a request to another page and just print the output but we cannot make a request to our own server. As I am aware, ASP doesnt offer this.
We could write a .NET extension to control this but we are looking for other options. I know that declining .NET is a stupid thing, but its a long story...
Is there a solution to this problem in ASP?
Have a look at Server.Execute it allows dynamic (run time) code inclusion of other ASP files. An added bonus is that it's treated as part of the original request so SESSION, COOKIE are all available in the included file. HOWEVER variables defined in the master are not available to the included the page. You circumvent this using temporary Session variables though.
Session("variable") = "value";
Server.Execute(url);
Session.Abandon;
Response.end;
Session.Abandon will clear ALL session variables, you might want to clear them individually.
You can make a request to your own server but the page making the request needs to NOT have session enabled in the page declaration right at the top of the page:
Each page locks the session object and its that which stops you making a request to your own server. If you declare you are not going to use session in the calling script then it wont lock it and you can run it again using a XMLRequest and pass what you like on the querystring, post data and session cookies too so session etc. will all still exist.
Related
With my recent development work, I need a way to determine whether the current response received is from Cache or if the Server has sent a very fresh response. This is so because there are some javascript codes that needs to be executed for every fresh response & NOT every fresh user.
You all may agree that showing the Javascript code Which Will be executed on every fresh response won't add anything meaningfull to my question, since it's totally irrelevant and not connected with the way a server respose is sent.
So, Is there any way to differentiate whether the response is from the Cache or is a new fresh copy sent by the server ??
You should consider creating a custom OutputCacheProvider that extends the built in cache provider used in MVC.
Some links that might help:
MSDN Article: Building and Using Custom OutputCache Providers in ASP.NET
Creating a Custom Output Cache Provider in ASP.NET 4
Custom Output Caching with MVC3 and .NET 4.0 – Done Properly!
Within your provider, you can use the same functionality as the regular output cache provider. And on the Get() action, you can add content to the item returned from the cache that will indicate that it was in fact retrieved from cache (you will want to experiment with this, making sure that you are only adding this to the items that you want, and are doing it in a way that doesn't mess up the output).
The ASP.NET MVC website I'm working on has some (Controller-derived) "user" pages and some (ApiController-derived) "api" pages.
The site uses MiniProfiler to instrument the "user" pages, and I really like what it does. I'd like to have the same or similar functionality in the "api" pages - specifically, a record of the SQL statements that were executed, and how long everything took.
I saw this link which looked promising, where the URL of the entry point is simply entered into the browser address bar, but that's using the default view that comes out of the box with ASP.NET MVC WebApi. My own URLs return an XML document (or JSON response).
Also, I'd prefer something that will allow me to get away from the browser, since my real-life API calls are initiated by another program, and I'd like to be able to record information about a whole session rather than just a single request.
Any advice?
You can have MiniProfiler log it's results to a database instead of disposing of the results. At that point you'll be able to look back at the performance over time (against a session or an end point).
Add:
MiniProfiler.Settings.Storage = new SqlServerStorage("connection string here");
to your settings and it should start logging to the database.
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.
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.
Is there a built-in asp.net way to conditionally serve pages, for example I want the following logic:
If there is a session data I generate
a page, if there is no session data I
serve the cached page.
I am only interested in knowing about a built-in asp.net mechanism for this. If it does not exist I am probably going to simply cache my page manually and decide whether to serve it or not for each request, based on the session data availability.
I don't think there is built-in support (like varyByParam) for generating fresh output for users with Session Data.
As you suggest, I would recommend manually caching the pages. I would probably determine the user's Session state in the PreRequestHandlerExecute event handler in the Global.asax and then maybe set:
HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache);
At the risk of karmabombing, I really don't like this approach to caching.
For me if a GET request is made, then a server should respond to that in good faith. Caching at a page level should be controlled by http headers because the primary goal is not to get the redundant request at all - you don't want to allocate server/bandwidth resources full stop.
Caching objects which are resources involved in making up a page I can totally get behind, but I can't see great arguments for caching a page wholesale.
Respect the headers.
You might want to look at the substitution control (Link) new in .NET 2.0, however it might not be exactly what you are after.