I'm developing a asp.net mvc website and want to implment some security features. One of them is to prevent the website from being injected in an iframe. I have read that it is possible to do that with x-frame-options which is a server side validation, but i have also read that it is required to implement client side validation with JS as well. Could anyone help me with that? Many thanks!!
the client side validaton can be done using the busting JS.
To implement the server side validation, you need (as you already mentioned) to set x-frame-options in IIS or in the application (Global asax file):
IIS:
<httpProtocol>
<customHeaders>
<add name="X-Frame-Options" value="DENY" />
</customHeaders>
</httpProtocol>
Global asax:
protected void Application_BeginRequest(object sender, EventArgs e)
{
HttpContext.Current.Response.AddHeader("x-frame-options", "DENY");
}
For more info about busting js, see this link:
https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
I have the same problem with old broswers, for example, mozilla 3.0
Hope this helps!
Related
I have a application hosted with domain www.abc.com .This is actually WebApi application . I want to build a separate UI application using asp.net mvc, and its domain is www.xyz.com.
The UI application consuming Angular,HTML5 and other Web technologies.Here i really need to perform GET,PUT,POST,DELETE against www.abc.com. unfortunately the limitation of jsonp , i like to choose CORS (HTML5 Cors), but i can't pass json object to CORS calls . what are the best possible best approach to call cross domain calls (GET,PUT,POST,DELETE) using angularJs with my problem scenario . What should i change in IIS to handle CORS request.
add below web.config in webapi
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
</httpProtocol>
</system.webServer>
and in angular, set below config options for $http
header("Access-Control-Allow-Credentials: true");
header("Access-Control-Allow-Origin: http://url.com:8080");
header("Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS");
header("Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization");
also check: this link
To enable cross domain ajax calls you can place crossdomain.config in asp.net web api root folder when published with following contents.
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*"/>
</cross-domain-policy>
Our shop is integrating ASP.NET MVC into a large web application that utilizes custom & 3rd party HTTP Handlers defined in web.config under system.webServer\handlers. Leveraging HTTP Handlers in this way has been great for us because we don't need to recompile the app or have the actual handler page sitting on disk somewhere in the web scope for each instance of the product.
Is it really necessary to add explicit Ignore Routes in our global.asax so the Runtime can honor our Handlers defined in web.config? I would have thought Web.Routing would be invoked after the handlers defined in system.webServer\handlers have been checked (not the other way around).
We use a modular design that allows adding/dropping Handlers from web.config when features are added. With the introduction of MVC routing it appears we need to add ignore routes in the global.asax file for every possible handler defined in web.config.
Note the actual file to these Handlers don't exist on disk - they are virtual and embedded in an assembly. Here's an example of a 3rd party handler that now requires an explicit Ignore Route in global.asax:
<system.webServer>
<handlers>
<!-- telerik radcontrols -->
<add name="TelerikDialogHandler" verb="*" path="Telerik.Web.UI.DialogHandler.aspx" type="Telerik.Web.UI.DialogHandler, Telerik.Web.UI, Version=2009.1.402.20, Culture=neutral, PublicKeyToken=121fae78165ba3d4"></add>
</handlers>
</system.webServer>
So for the record if you use System.Web.Routing you must include Ignore Routes for Http Handlers specified in Web.Config? Or perhaps I'm doing something wrong?
ASP.NET request processing is based on a pipeline model in which ASP.NET passes http requests to all the modules in the pipeline. Each module receives the http request and has full control over it. Once the request passes through all of the HTTP modules, it is eventually processed by an HTTP handler. The HTTP handler performs some processing on it, and the result again passes through the HTTP modules in the pipeline.
I think that the best way to think about these is that HttpModule is a filter that adds or subtracts something from the request object when an event occurs and the HttpHandler is a processor that actually serves the request. The ASP.NET request lifecycle is setup in such a way that all filters are applied to the request first before processing occurs.
I want handle the requests to my application "http://example.com/whateverpath" by a custom HttpHandler but the return things depending of the value of "whateverpath".
So users accessing "http://example.com/path1" will get different response than users accessing "http://example.com/path2", but both request must be handled in the same HttpHandler. The idea is find "whateverpath" in a database and depending of the result, return the response content.
I hear about URL routing and I already have a custom Http handler working, but can I combine both technique to get what I need?
I will appreciate any comment respect this issue.
Cheers
Frank Abel
So you have a class that implements IHttpHandler called: MyHandler and it's in the namespace Example, you need to make the following entries in the site's Web.Config in the httpHandlers section:
<httpHandlers>
<add verb="*" path="*" type="Example.MyHandler"/>
</httpHandlers>
Since this redirects all URLs for your web site/application to your handler you have to consider how to serve static content (imgs, scripts, style sheets etc). One way is to store such static content in a consistent URL like http://example.com/static/..., you can then set your handlers as such:
<httpHandlers>
<add verb="*" path="*" type="Example.MyHandler"/>
<add verb="GET,HEAD" path="static/*" type="System.Web.StaticFileHandler" />
</httpHandlers>
For your local dev webserver (embedded in Visual Studio) this is all that's needed. For IIS, you also need to tell IIS how to deal with these URLS (since the server first analyses a request to decide where to send it - including whether to send it to ASP.NET or some other extension).
Open: IIS Manager ->
Section: Websites ->
Right click on your website ->
Option: Properties ->
Tab: Home Directoy ->
Button: [Configuration...] ->
Tab: Mappings ->
Section: "Wildcard application maps (order of implementation):" ->
Button: [Insert...] ->
Executable: "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" (or whichever version of the .NET runtime your handler uses) ->
Uncheck "Verify that file exists" ->
Button: [OK]
Now both IIS and ASP.NET know how to deal with your URLS.
The above approach means when requesting static files, ASP.NET is actually serving the files, not IIS - which leads to a few disadvantages (discussed here). You can override this behaviour (disable wildcard mapping from the static directory) by switching the directory to an application (in IIS Manager), removing the wildcard mapping statement (added above) and switching it back from an application. Voilà - static files are handled by IIS without pestering your ASP.NET.
I do not recommend combining URL routing and HTTP handlers.
This seems like a perfect job for URL routing. However, I would not use an HTTP handler for it.
Simply map "~/CustomData/whateverpath" to an ASPX page. Then have the page load the data from the database. Afterall, if the logic to look up the data is the same no matter what "whateverpath" is, you don't want to repeat your logic for every variation. Instead, you want to map it to a single file that will load the correct data for all cases.
HTTP handlers are a completely different matter and should not be used for this purpose. (BTW, I just published an article on HTTP handlers. You can view it at http://www.blackbeltcoder.com/Articles/asp/writing-a-custom-http-handler-in-asp-net).
First off, I would concur with the previous post by Jonathan Wood, that using routing within HttpHandler isn't a good idea. But I am pretty sure he was referring to the standard MVC routing there.
A good approach would be in using custom routing. I published an article about it - Basic Routing for HttpHandler
I have plugged in the HttpCompress module to enable compression for my MVC web application.
If I run my site through the development web server (Cassini) I have no troubles with the execution of compression.
However when I deploy the site to IIS6 the compression is not executing. I have checked the source code of the compression library and the CompressContent handler returns without acting becuase a null value exists for
app.Request.Headers["Accept-Encoding"]
My best guess is that this has something to do with the handling of extensionless urls in IIS6. What do I need to do to fix this problem in production?
[ below is the config for the module, if that is of any assistance ]
<blowery.web>
<httpCompress preferredAlgorithm="deflate" compressionLevel="high">
<excludedMimeTypes>
<add type="image/jpeg" />
<add type="image/png" />
<add type="image/gif" />
<add type="application/pdf" />
</excludedMimeTypes>
<excludedPaths></excludedPaths>
</httpCompress>
</blowery.web>
Some further investigation discovered that I was accessing the server via a proxy, and it appears that the proxy was not forwarding the compression headers to IIS.
It seems the easiest way to identify a proxy meddling with the request is to check the response headers for a via entry.
See the complete list of http headers as a homework task.
My ASP.NET MVC application is within a folder called Stuff within IIS 6.0 webroot folder. So I access my pages as http://localhost/Stuff/Posts. I had EMLAH working while I was using the in-built webserver of Visual Studio. Now when I access http://localhost/Stuff/elmah.axd, I get resource not found error. Can anyone point my mistake here! Here is config file entry,
<add verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah"/> //Handler
<add name="ErrorMail" type="Elmah.ErrorMailModule, Elmah"/>
<add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah"/>
<add name="ErrorFilter" type="Elmah.ErrorFilterModule, Elmah"/> //Module
Working with IIS7 I found I needed both sections of the web.config populated (system.web AND system.webServer) - see Elmah not working with asp.net site.
Perhaps this is related.
Have you added an ignore *.axd routes in global.asax?
For Elmah, we need to differentiate between two things:
First the http modules doing all the work of error logging, emailing...etc.
Second, the http handlers, displaying the error log page and other pages (rss...etc.)
I was having the same problem of 404 resource not found because I have a weird setup!
on my development machine, (windows 7, iis 7 ) elmah was working like a charm because the application pool was working in the integrated pipeline mode. In the production machine, however, the application was using the managed pipeline and I tried all my best to make elmah work but it was all useless...
I then got the idea of displaying the UI (error log page, rss, error detail,...) using regular aspx pages.
I downloaded the source code, made some changes (sorry Atif, I was forced to do this because I needed the quickest solution) and then in my application , I created a folder under which I created regular aspx pages which inherits from Elmah defined pages.
The page only contains one line (ex: for the detail page: <%# Page Language="C#" Inherits ="Elmah.ErrorDetailPage"%>)
Now, I was able to run Elmah regardless of IIS 6/7 and it is working like a charm.. and It saved me from a big headache of correctly configuring http handlers and troubleshooting its work! additionally, configuring security is much simpler!
I don't know if the community is interested in this solution (If so, I am ready to post my full changes).
Hope that this gives you an idea on how to solve the problem in an alternative way (and if you need the modified dll with complete instructions on how to use it, just tell me!)
In the application pool settings in IIS set Managed Pipelin Mode to Classic if you don't want to change code or the web.config file. Your axd.s will then work as before.
Can you post the rest of your web.config?
Or, if you're comfortable enough, can you just ensure that the httpHandlers and httpModules (NOT handlers and modules) sections are filled in properly in the web.config?