NWebsec's "A potentially dangerous redirect was detected" with Facebook logon - facebook

I have read through NWebSec's documentation to try and resolve the problem.
Set the web.config to
<nwebsec>
<httpHeaderSecurityModule
xsi:noNamespaceSchemaLocation="NWebsecConfig/HttpHeaderSecurityModuleConfig.xsd"
xmlns="http://nwebsec.com/HttpHeaderSecurityModuleConfig.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<redirectValidation enabled="false">
<allowSameHostRedirectsToHttps enabled="false"/>
<add allowedDestination="https://www.facebook.com/"/>
<add allowedDestination="http://www.nwebsec.com/"/>
<add allowedDestination="https://www.google.com/accounts/"/>
</redirectValidation>
<securityHttpHeaders>
<strict-Transport-Security max-age="365" includeSubdomains="true" httpsOnly="false" preload="true" />
</securityHttpHeaders>
</httpHeaderSecurityModule>
but I am still getting
A potentially dangerous redirect was detected. Add the destination to the whitelist in configuration if the redirect was intended. Offending redirect: https://www.facebook.com/dialog/oauth?response_type=code&

This came up in google before the answer, which is here: https://docs.nwebsec.com/en/latest/nwebsec/Redirect-validation.html
In summary you have to whitelist the URL which your login service refers to, like this:
app.UseRedirectValidation(opts =>
{
opts.AllowedDestinations( "https://www.facebook.com/dialog/oauth");
opts.AllowedDestinations("https://login.microsoftonline.com"); // Tested
});

Related

How do I hook into IDP initiated single logout to run custom code?

I'm using sustainsys.saml2.httpmodule. I would like to run some code to log the logout from an IDP initiated single log out. The user also does not seem to be logged out (IsAuthenticated is still true) after an IDP initiated single log out even though https://stubidp.sustainsys.com/Logout gives me a success result.
I can't seem to find anyone else needing the same functionality or having the same issues. My Sustainsys config is below.
<sustainsys.saml2 entityId="http://localhost:53758/Saml2"
returnUrl="http://localhost:53758/Common/Pages/Saml2Login.aspx"
authenticateRequestSigningBehavior="IfIdpWantAuthnRequestsSigned"
validateCertificates="false"
publicOrigin ="http://localhost:53758/">
<nameIdPolicy allowCreate="false" format="Unspecified"/>
<metadata cacheDuration="PT1440M" wantAssertionsSigned="true">
<organization name="ab" displayName="ab" url="https://www.example.com/" language="en" />
<contactPerson type="Technical" email="a#b.com" />
<requestedAttributes>
<add friendlyName ="Some Name" name="urn:someName" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true" />
</requestedAttributes>
</metadata>
<identityProviders>
<add entityId="https://stubidp.sustainsys.com/Metadata"
signOnUrl="https://stubidp.sustainsys.com"
logoutUrl="https://stubidp.sustainsys.com/Logout"
allowUnsolicitedAuthnResponse="true"
binding="HttpRedirect"
wantAuthnRequestsSigned="true">
<signingCertificate storeName="CertificateAuthority" storeLocation="CurrentUser"
findValue="cdf7090a433561a843b51198b0ba6456" x509FindType="FindBySerialNumber" />
</add>
</identityProviders>
<serviceCertificates>
<add storeName="CertificateAuthority" storeLocation="CurrentUser" findValue="2cfe21cb930c19a341e9e30a07a3c123" x509FindType="FindBySerialNumber" />
</serviceCertificates>
</sustainsys.saml2>
You can use the LogoutCommandResultCreated notification. It will get called both when the redirect to the Idp is about to happen as well as after the response has been received from the Idp.

UseOpenIdConnectAuthentication kills postback

I am trying to include SSO with office 365 for one of our web applications.
the problem is that as soon as SSO is working all my postbacks are getting ignored.
what I did was the following,
I installed those Nuget Packages
- Microsoft.Owin
- Microsoft.Owin.Host.SystemWeb
- Microsoft.Owin.Security
- Microsoft.Owin.Security.Cookies
- Microsoft.Owin.Security.OpenIdConnect
- Owin
I created an app in my AAD
then I've added some settings to my web.config
<add key="ida:PostRedirectUri" value="http://localhost:4439" />
<add key="ida:ClientId" value="XXXXXXX" />
<add key="ida:AADInstance" value="https://login.microsoftonline.com/" />
<add key="ida:Tenant" value="XXXX.onmicrosoft.com" />
<add key="ida:PostLogoutRedirectUri" value="http://localhost:4439" />
and I added Startup.vb to my solution with the following content
app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType)
app.UseCookieAuthentication(New CookieAuthenticationOptions())
app.UseOpenIdConnectAuthentication(New OpenIdConnectAuthenticationOptions() With {
.ClientId = clientId,
.Authority = authority
})
app.UseStageMarker(PipelineStage.Authenticate)
and after this the SSO works however al postbacks on buttons fail
if I click a button the page just gets reloaded.
also the IsPostBack parameter is alwayst false.
What I found was that when I remove the "app.UseOpenIdConnectAuthentication" part, postbacks are working again, but SSO is not.
how can I make sure my postbacks are working and I can also use UseOpenIdConnectAuthentication ?
thank you.
I found the issue,
in my web.config I had
<modules runAllManagedModulesForAllRequests="true">
in system.web
removing the key "runAllManagedModulesForAllRequests" solved the problem
<modules>

Redirect old domain to new domain keeping url

We are releasing a new version of our Web app and in the process doing a branding change with a new domain also.
Both our apps are hosted in Azure.
Current App - Cloud Service
New App - Azure Website
What I want to achieve is redirect any old links from the old domain to the new domain while keeping the url portion.
Example:
User visits
https://my.currentdomain.com/any/link
and will be directed to
https://my.newdomain.io/any/link
Do I do a CNAME from currentdomain to newdomain and then a URL Rewrite in my web.config??
Thanks!
Update - I've test this locally and it does what I'm looking for. I'll just point the cname of the old domain to the new domain and this redirect should pick up the links.
<rule name="Redirect to new domain" stopProcessing="true">
<match url="^(.*)$" />
<conditions>
<add input="{HTTP_HOST}" matchType="Pattern" pattern="^olddomain(:\d+)?$" />
</conditions>
<action type="Redirect" url="https://my.newdomain.io/{R:1}" redirectType="Permanent" />
</rule>
The fact that you host your application in Azure has minimal to no impact on the solution you are going to find.
When you do such things, you usually want to also keep all the credits that you have in the search engines. And you can only achieve that if your https://my.current.domain.com/any/link does a HTTP 301 Redirect Permanent to the new location.
Depending on the size and complexity of your project this can be a trivial task or not so easy.
One option, which is valid only if you want to redirect few (like a dozen) links. You can do that directly in your Web.Config file:
<location path="any/link">
<system.webServer>
<httpRedirect enabled="true" destination="https://my.newdomain.io/any/link" httpResponseStatus="Permanent" />
</system.webServer>
</location>
This of course makes no sense when you have a bunch of links, or even a whole CMS behind the scenes. If this is the case, I would opt-in for writing a custom HTTP Module for IIS. This module will have the sole purpose of inspecting the incoming URI and either let it further, or generate HTTP 301 redirect.
If you are using the latest and the greatest from Microsoft, the same (custom HTTP Module) can be achieved with a custom OWIN Middleware.
If it is just domain change, all paths and query strings are to be kept, check out this good article how can you do this with URL Rewrite under IIS.
add this code to your header file:
<script type="text/javascript">
// Get Current URL
var url = window.location.href;
// Replace domain in URL
var newurl = url.replace("olddomain.com", "newdomain.com");
// Redirect to new URL
document.location = newurl;
</script>

Facebook Like button won't show on Azure website http

I've got an azure website (at http://ekpowestore.azurewebsites.net/) that won't show a Facebook like button in Explorer or Firefox. It does in Chrome and Safari. Yet if I change the address to https (as in https://ekpowestore.azurewebsites.net/), the Like and Share buttons render just fine.
Liking an https isn't the same as http. I guess I can refer folks to the https site, but I'm still curious about what the root cause is.
Of course, I tried about 100 different things before finally throwing up a nearly empty page on my azure site.
seems your page returns 307 "Internal Redirect" while trying to load the Facebook script on HTTP request. I am not sure, but you possibly used "Protocol relative" referencing on your javascript like
js.src = "//connect.facebook.net/en_US/sdk.js";
which will redirect the action with using the current protocol (https://connect.facebook.... if you are using HTTPS or to HTTP). Could you please try to replace it with full url to give it a try ?
eg.
js.src = "https://connect.facebook.net/en_US/sdk.js";
I give up. This isn't the actual answer to the o.p., so I won't mark it as such. But it is what I did to address the problem - So perhaps someone will find this useful.
Note that I did take the entire app down to just an html doc with a facebook like plugin in it - No other dependencies - And yet then still IE and FF no love, Safari and Chrome fine. This was both using a protocol relative Facebook path (i.e. - "//connect.facebook.net/en_US/sdk.js") and a specified https path (i.e. "https://connect.facebook.net/en_US/sdk.js")
So rather than fight the http - https mixed content war that Gaurav pointed out may have been happening with the Facebook reference, I changed the Azure site so it always forwards http to https. Problem solved, moving on ('problem solved' being slightly different than 'question answered').
Added a web.config file consisting of the following worked for me:
````
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<rewrite>
<rules>
<rule name="Redirect HTTP to HTTPS" stopProcessing="true">
<match url="(.*)"/>
<conditions>
<add input="{HTTPS}" pattern="^OFF$"/>
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="SeeOther"/>
</rule>
</rules>
</rewrite>
</system.webServer>

AppHarbor - Why is my <httpRuntime maxRequestQueryStringLength="XXXX"/> not working?

I have a long querystring value I need to pass in (itself a questionable practice, I understand), and I am not able to get it to take effect on my Appharbor app instance.
Locally, I've made this change to my web.config and confirmed that the URL in question works locally:
<httpRuntime maxQueryStringLength="2097151"/>
And ensured that it exists in the resultant web.config post the transformation by my Web.Release.config. That said, when I push to AppHarbor, the transformation should pick it up...yet I'm still getting this exception:
The length of the query string for this request exceeds the configured maxQueryStringLength value.
Stack Trace:
at System.Web.HttpRequest.ValidateInputIfRequiredByConfig()
at System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)
Any ideas? Thanks for your help.
My original testing was done against Cassini (VS 2010's built-in web server). I pushed locally to IIS 7.5 and found this error:
HTTP Error 404.15 - Not Found
The request filtering module is configured to deny a request where the query string is too long.
Which appeared because I didn't specify the maxQueryLength in the <system.webServer> section of my web.config as well as the <httpRuntime>. So the answer is to specify BOTH the <system.web> and <system.webServer> sections:
<system.web>
<httpRuntime maxQueryStringLength="2097151"/>
</system.web>
And then:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxQueryString="2097151"/>
</requestFiltering>
</security>
</system.webServer>
When I pushed this version of my config to AppHarbor, all was well. Hope this helps.
Remember that HTTP.SYS has its own limits as well!
They're described here: http://support.microsoft.com/kb/820129