This is not a question that I'm asking, but an answer that I'm giving for to a problem that had been plaqueing me for a few days.
We were tasked to build a simple static ASP.Net application with a sign-in to access the site. We decided to go with Forms Authentication for this, and the site itself only contains about a dozen pages. We were asked to use Veracode to address any security flaws, and kept coming up against a security threat around the Response.Redirect. Veracode kept saying that we needed to evaluate against a whitelist of domains and try to button up this security flaw, but we found a simple solution for this with built in Forms Authentication.
For this solution, there are 2 things that you need.
First, the web.config. On your tag, make sure that you have the following attribute:
<forms enableCrossAppRedirects="false" ></forms>
This makes sure that any redirect link that is returned through the query string is a local redirect only. It will not allow for any links outside of your site to be resolved.
Next, in the code behind of your login page, You will only need the following line of code:
FormsAuthentication.RedirectFromLoginPage(username, false, "/");
This ensures that the redirect follows the rules that are setup in the web.config, and also sets the cookie for you.
Pre-compile your application again in Visual Studio, or use the plugin to upload and scan from there, and be amazed as it passes the validation.
Related
I included BotDetect Captcha in my login page but the captcha control is not loading. I tried a simple page based on examples but still captcha is not working/loading
Here are the config lines : webconfig
Your help is highly needed and appreciated
You can try reCAPTCHA which have provision to run on local
"If you would like to use "localhost" for development, you must add it to the list of domains."
Even though it allows to run on local server but can only work if you access localhost using 127.0.0.1 rather than localhost.
Here is the reCAPTCHA .link for reference
I have a very basic Single Sign On app built on VS 2015 using MVC and Web Forms. It is supposed to be a simple proof of concept and is based on some code found here and here which are essentially the same things. I've finally gotten it all converted to use .Net 4.5 but when running it on my local server it throws a 404 with no debug information.
The 404 itself wasn't initially a surprise as I was supposed to be able to change the url to one of the secure pages (for instance /WebSecApp1) which would redirect me back to the signon page but no matter what I put as the url I get the 404.
I've also tried changing the urls in the code so that they contain the port numbers for the localhost but that doesn't work either.
It was suggested to me that the RouteConfig.cs could be the culprit but I don't see how that could be since I'm calling a single page with no parameters.
I know this is kind of lite on details but does anyone have any suggestions?
Yes this looks like a routing issue as you also thought it to be. Routing is essential for web api too .Pls see https://www.asp.net/web-api/overview/web-api-routing-and-actions/routing-and-action-selection. Does your api request look like this
GET http://localhost:34701/api/products/1?version=1.5&details=1
You do have to mention the port in the request.
While the routing that Arathy mentioned above was partially to blame, the real problem turned out to be relatively simple. In my case simply selecting Properties->Web for each of offending pages and setting "Override application root URL" to checked fixed the whole problem.
I am working with provider hosted app using MVC with JQuery and have a requirement to show Provider Hosted App in an iframe in a SharePoint page to make it look like it is integrated in SharePoint. This application contains a report viewer(version 10.0.0.0) which is showing 'Asp.net session has expired or could not be found' when viewed in IE10 or higher. This app in a SharePoint page works fine when viewed in any other browser(Chrome, Mozilla) but not in IE.
Observations:
When the application is running directly in the Browser i.e.without using iframe, it is working fine.
When the Sharepoint page is viewed after opening the application directly in the browser i.e. in different tab, it works without any error.
But when viewed opening browser for the first time and no instances of the application are opened directly in the browser, it shows the error:
'Asp.net session has expired or could not be found'
Things already tried:
Increasing timeout for iframe as well as application in web.config file.
Setting report Viewer's KeepSessionAlive and AsyncRendering to false as well as true.
Reporting server timeout and all configurations.
Using sessionMode to InProc, SQLServer.
setting cookieeLess to true.
None of these are working for my scenario and I am struggling with this for a week. It seems like some registering problem at the first time and when the application is directly opened it gets registered and works. Any help will be highly appreciated.
P.S.: I have registered the report viewer in web.config file.
Thanks.
So guys finally i fixed my own issue. Thanks to the hint provided by mwwallace8 in the comments.
Problem: IE doesn't allow us to store third party session data in the form of cookies. This is because it gives lower level of trust to iframe pages, thus no session data for iframe will be stored in cookies. So when we submit the form and make a post call the server doesn't receive any session data in the request and thinks that it is the first request. This process generates a new Session ID and sends it back in the response. When the response comes back, the Session ID in the response and the is the new one and it thinks that the previous session expired.This generates the above problem.
Unlike when we open the application directly in the new tab, it takes it like first party and stores its session data in the form of cookies.
Because of this once we open the app in new tab directly, everything was working flawlessly.
Solution: IE needs P3P headers(Platform for Privacy Preference Project) to authenticate the session running in the iframe. This header will tell about what is the intent of the iframe session and what kind of data it will take from browser cookies. It is kind of swiping the Access card before entering in an IT company. So the question is how to generate this P3P header? The answer is here: Go to web.config file and add this code in Configuration tag
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="p3p" value="CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT""/>
</customHeaders>
</httpProtocol>
</system.webServer>
This will create a header certificate i.e. P3P header certificate which will authenticate the iframe session data to get stored in the browser cookies.
To know what these value actually means, go to This Link. You will find a whole lot of information about P3P headers in here.
Hope this might help someone.
Cheers..
Here is the situation: there has been an application for years. It's old and should not be used. Therefore I created a whole new application to replace the other. Now I want to show a piece of information to the users trying to access the old one (regardless whether already authenticated or, which is more likely, not yet authenticated) and a link to the new one.
I don't want to change anything in the old one or just change as few things as possible, it should stay. So I came up with an idea: why not backing up current Default.aspx and then creating new Default.aspx telling users to try and use the new application (maybe slightly modifying web.config but how?). However, when an unauthenticated user enters ~/Default.aspx, she gets redirected to the login page.
Is it possible to allow unauthenticated users to see this default page without getting redirected to the login page just to give their credentials and then see the default page telling that there is the other application?
Are you just looking to "announce" that users should go to the "new" application (and not do an auto-redirect)?
IF SO, then wouldn't a simple html page that made this announcement be your "linker"?
The reason I'm suggesting .html (instead of an .aspx page) is that if you "don't want to change anything" in the old site, then an html page/file takes it out of the "ASP.Net pipeline" (asp.net will not process it, IIS will) - I'm guessing that the entire old application requires authentication because you mentioned the default.aspx (normally the default document of the web site/application) already requires a login (which is why it redirects).
You can set the "old" application default document to be this (new) standard "announcement" page.
Hth...
I am working on a site which is programmed in C# .net. It uses a CMS called ADX Studio (a decision which predates my time there) which provides a shonky form of URL Rewriting (as far as I can tell it works by assigning an aspx page as the default 404 handler in IIS).
I have an web form which lives at a rewritten URL. I edited it so that the html form's action points back to the rewritten URL:
var u = new Uri(Request.RawUrl.Split(new char[1] { ';' }).Last());
userAdminForm.Action = u.PathAndQuery;
(kind of ugly but works based on what Request.RawUrl is on these rewritten URLs).
The "pretty" URL is something like this:
http://www.site.com/admin/user/edit/
On my development box (Windows XP/ IIS 5) when I initially tried POSTing back to URLs like this I got a HTTP 405 error. I worked around this by adding a script mapping so Aspnet_isapi.dll handles all (*) requests. And everything works fine on my development machine.
I just pushed my changes to the live server (Windows Server 2003 R2 and IIS 6) and the post fails silently. The page refreshes but all of my logic (from within an IsPostBack path in the code) doesn't get hit. No errors are displayed, it just doesn't work.
If I remove my code setting the .Action of the form then the postback works but it is posting to the ugly URL corresponding to the physical location of the aspx file rather than my page.
Am I missing a simple way to make this work? I don't want to be switching URL rewriting method or anything as this is a large legacy site and is unfortunately pretty dependent on ADX Studio so I don't want to do anything that will break that.
[edited because somehow the code above lost its code highlighting]
The issue is that the page's <form> tag is referencing the "ugly" url as the action. You can resolve that by completely removing the action tag from the form. Browsers will, by default, postback to the same page, ie. the "pretty" url.
This article explains how to accomplish an "actionless" form (~ two thirds of the way down) http://msdn.microsoft.com/en-us/library/ms972974.aspx
It seems like the problem is the same as it was on IIS 5. I can get it to work by doing the following in the IIS Manager:
Right click on the relevant website and select "Properties"
Choose the "Home Directory" tab
Click "Configuration" down in the "Application settings"
Click "Insert" next to the "Wildcard application maps"
Browse to the location of aspnet_isapi.dll (in my case: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll )
Untick "Check that file exists"
Click "OK" back through the Russian doll of dialogs.
This is basically the same as the approach that I linked to in the question for IIS5. However, it's not optimal because IIS is running every request through asp (even static files). Which seems like it can only slow things down. I'd like to be able to specify that asp only needs invoking for HTTP POST requests at least.
The weird thing is that IIS5 gave a HTTP 405 error when POSTing to an extension without a registered ISAPI extension but IIS6 just fails silently. And the page is being run through IIS (I can debug with a breakpoint in the Page_Load function) but IsPostBack (and IsCrossPagePostBack) don't get correctly set. Could it be related to the view state? Is there any alternative to my solution described above?
I've come to what I think is an optimal solution for this problem. It turns out that ADXStudio CMS does use the default 404 rule to do some form of URL rewriting. This has a problem with http POST:
when IIS initially executes a custom
URL on a 404 error, it changes POST to
GET, even if the client does a POST
request.
(thanks to elite brains' blog post about setting up IIS6 and ASP.NET MVC).
Rather than creating my own HttpModule I decided instead to use Ionics Isapi Rewrite Filter to rewrite my URLs. I then set the 404 error handler in IIS to the default. And I created this IIRF.ini file to redirect all requests to the same format as the 404 handler produced:
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /Default.aspx?404;http://%{HTTP_HOST}$1 [U,L]
And everything seems to work great. The advantage over my previous answer is that the rewrite code is low level and runs fast and the -f and -d switches mean that if a file actually exists it isn't re-written and so static files don't have the overhead of running through .net.