We are implementing cross site scripting protection in MVC5 by using the built in ValidateAntiForgeryToken attribute and #Html.AntiForgeryToken() helper.
This all works. However, our app runs in a frame that is in a different domain. So, we need to set the cookie to SameSite=none (as we have done with session and auth cookies).
I can't find a way to configure the cookie to include this setting.
I have tried to create an OWIN middle ware to check the cookies on the way out and update it, but the cookie collection in the response in the OWIN context is read only.
How can I get this setting on the cookie?
Adding this to global.asax.cs to set the token to Same Site = none should fix it
protected void Application_PreSendRequestHeaders(object sender, EventArgs e)
{
// This code will mark the __RequestVerificationToken cookie SameSite=None
if (Request.Cookies.Count > 0)
{
foreach (string s in Request.Cookies.AllKeys)
{
if (s.ToLower() == "__requestverificationtoken")
{
HttpCookie c = Request.Cookies[s];
c.SameSite = System.Web.SameSiteMode.None;
Response.Cookies.Set(c);
}
}
}
}
Related
I'm renaming the cookie and made it to target to a different path, rather than targeting to a default path "/".
Below is the web.config settings:
<sessionState sessionIDManagerType="MyNamespace.MySessionIDManager" cookieName="AppCookie"/>
Below is the backend class used to create the cookie:
public class MySessionIDManager : SessionIDManager, ISessionIDManager
{
void ISessionIDManager.SaveSessionID(HttpContext context, string id, out bool redirected, out bool cookieAdded)
{
base.SaveSessionID(context, id, out redirected, out cookieAdded);
if (cookieAdded)
{
var name = "AppCookie";
var cookie = context.Response.Cookies[name];
cookie.Path = "/Forms";
}
}
}
This fix is working fine for me locally. The cookie is successfully pointing to the given path i.e "/Forms".
But when I deploy my application to IIS, I'm not able to login to the application.
It is not throwing any error, but not allowing me to login to the web application.
If I use to below web.config settings, it is working fine.
<sessionState mode="InProc" timeout="30" cookieName="AppCookie" />
Please let me know what issue it is causing in the IIS.
Any input is much appreciated.
Thank you all in advance.
Thanks and Regards,
Dada.
please try to change the URL from http://www.website/login/ to http://www.website/forms/login/ and then you can see the cookie will send in the request header, and you will auto login.
This is caused by you change the cookie URL to /forms, it means that only the http URL has /forms string will send the session cookie which has created with the aspnet_sessionID.
If you don't change the cookie URL, default path '/' means the cookie can be shared.
You can see this link: https://learn.microsoft.com/en-us/dotnet/api/system.web.httpcookie.path?view=netframework-4.8
I fixed this issue with the below piece of code;
public class CookieManager : SessionIDManager, ISessionIDManager
{
void ISessionIDManager.SaveSessionID(HttpContext context, string id, out bool redirected, out bool cookieAdded)
{
base.SaveSessionID(context, id, out redirected, out cookieAdded);
if (cookieAdded)
{
SessionStateSection sessionStateSection = (System.Web.Configuration.SessionStateSection)ConfigurationManager.GetSection("system.web/sessionState");
var cookie = context.Response.Cookies[sessionStateSection.CookieName];
cookie.Path = context.Request.ApplicationPath;
}
}
}
And update the web.config as follows;
<sessionState sessionIDManagerType="ANJU.Reports.WebUI.Library.CookieManager" timeout="30" cookieName="CookieName"/>
Now when I host my application on the IIS, it'll fetch the directory where I have my build.
All my cookies will point to the root directory of the build.
So I've built and published a new website that uses Azure B2C as the authentication mechanism.
What I found was that the login and sign would work fine for a while. But after a period of time, say couple of hours after visiting the site post deployment, I would find that on login or signup, after successful authentication, instead of being redirected back to the return url set up in the b2c configuration, my browser would get caught between an infinite loop between the post authentication landing page that is protected with an authorise attribute and the Azure B2C Login page, before finally finishing with Http 400 error message with the message - Bad Request - Request too long.
I did some googling around this and there are number of posts that suggest that the problem is with the cookie, and that deleting the cookie should resolve the issue. This is not the case. The only thing I have found to fix this is restarting the application on the webserver, or waiting say 24 hours for some kind of cache or application pool to reset. Anyone has any ideas what's going on here?
Ok, I think I may have found the answer.
Looks like there is an issue with Microsoft.Owin library and the way it sets cookies. Writing directly to System.Web solves this problem according to this article.
There are three suggested solutions:
Ensure session is established prior to authentication: The conflict between System.Web and Katana cookies is per request, so it may be possible for the application to establish the session on some request prior to the authentication flow. This should be easy to do when the user first arrives, but it may be harder to guarantee later when the session or auth cookies expire and/or need to be refreshed.
Disable the SessionStateModule: If the application is not relying on session information, but the session module is still setting a cookie that causes the above conflict, then you may consider disabling the session state module.
Reconfigure the CookieAuthenticationMiddleware to write directly to System.Web's cookie collection.
I will opt for the third option, which is to overwrite the default Cookie AuthenticationMiddleware, as they have suggested below.
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
// ...
CookieManager = new SystemWebCookieManager()
});
public class SystemWebCookieManager : ICookieManager
{
public string GetRequestCookie(IOwinContext context, string key)
{
if (context == null)
{
throw new ArgumentNullException("context");
}
var webContext = context.Get<HttpContextBase>(typeof(HttpContextBase).FullName);
var cookie = webContext.Request.Cookies[key];
return cookie == null ? null : cookie.Value;
}
public void AppendResponseCookie(IOwinContext context, string key, string value, CookieOptions options)
{
if (context == null)
{
throw new ArgumentNullException("context");
}
if (options == null)
{
throw new ArgumentNullException("options");
}
var webContext = context.Get<HttpContextBase>(typeof(HttpContextBase).FullName);
bool domainHasValue = !string.IsNullOrEmpty(options.Domain);
bool pathHasValue = !string.IsNullOrEmpty(options.Path);
bool expiresHasValue = options.Expires.HasValue;
var cookie = new HttpCookie(key, value);
if (domainHasValue)
{
cookie.Domain = options.Domain;
}
if (pathHasValue)
{
cookie.Path = options.Path;
}
if (expiresHasValue)
{
cookie.Expires = options.Expires.Value;
}
if (options.Secure)
{
cookie.Secure = true;
}
if (options.HttpOnly)
{
cookie.HttpOnly = true;
}
webContext.Response.AppendCookie(cookie);
}
public void DeleteCookie(IOwinContext context, string key, CookieOptions options)
{
if (context == null)
{
throw new ArgumentNullException("context");
}
if (options == null)
{
throw new ArgumentNullException("options");
}
AppendResponseCookie(
context,
key,
string.Empty,
new CookieOptions
{
Path = options.Path,
Domain = options.Domain,
Expires = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc),
});
}
}
I will give that a crack, and post my results back here.
In my Azure Mobile .NET backend I want to use Azure Mobile .NET Server Swagger . I'm looking for fast way to hide swagger UI from public access ? Is there any way to provide access only for selected users ?
First a disclaimer: Even if you protect your Swagger UI from public consumption, you are not protecting your APIs from public consumption. You have to assume that everyone knows all of your routes and have the appropriate security in place to protect any requests that may come in.
That being said, there's still not a simple way to do this. Swashbuckle (the piece that adds Swagger to Web API) adds a custom HttpMessageHandler to the /swagger/ui route (as seen here). If you look at the Web API pipeline, you can see that if you specify a custom handler, you can bypass all of the Controller selection, Auth filters, etc. This is what happens here.
Some solutions:
Use an app setting to conditionally call ConfigureSwagger(config) in debug modes only. This would prevent all /swagger routes from making it into production. Or you could use a staging slot and only add it there.
You can wrap the SwaggerUiHandler with something like this Basic Auth MessageHandler. This would prompt the user for basic creds if they went to the /swagger/ui route. See below for my modified version of this code.
Maybe with a little more thought we can come up with a better solution -- I see a couple of issues (here and here) in the Swashbuckle repo that indicate you're not the first one to hit this.
Modified BasicAuthHandler (from here):
Warning: minimally tested (and be sure to change how you verify user/pass)
public class BasicAuthMessageHandler : DelegatingHandler
{
private const string BasicAuthResponseHeader = "WWW-Authenticate";
private const string BasicAuthResponseHeaderValue = "Basic";
public BasicAuthMessageHandler(HttpMessageHandler innerHandler)
{
this.InnerHandler = innerHandler;
}
protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
{
AuthenticationHeaderValue authValue = request.Headers.Authorization;
HttpResponseMessage unauthorizedResponse = request.CreateUnauthorizedResponse();
if (authValue != null && !string.IsNullOrWhiteSpace(authValue.Parameter))
{
Credentials parsedCredentials = ParseAuthorizationHeader(authValue.Parameter);
if (parsedCredentials != null)
{
// TODO: Check that the user/pass are valid
if (parsedCredentials.Username == "user" &&
parsedCredentials.Password == "pass")
{
// If match, pass along to the inner handler
return base.SendAsync(request, cancellationToken);
}
}
}
else
{
// Prompt for creds
unauthorizedResponse.Headers.Add(BasicAuthResponseHeader, BasicAuthResponseHeaderValue);
}
return Task.FromResult(unauthorizedResponse);
}
private Credentials ParseAuthorizationHeader(string authHeader)
{
string[] credentials = Encoding.ASCII.GetString(Convert
.FromBase64String(authHeader))
.Split(
new[] { ':' });
if (credentials.Length != 2 || string.IsNullOrEmpty(credentials[0])
|| string.IsNullOrEmpty(credentials[1])) return null;
return new Credentials()
{
Username = credentials[0],
Password = credentials[1],
};
}
}
Registering with Swagger route
// Do this after calling ConfigureSwagger
ConfigureSwagger(config);
// Remove the swagger_ui route and re-add it with the wrapped handler.
var route = config.Routes["swagger_ui"];
config.Routes.Remove("swagger_ui");
config.Routes.MapHttpRoute("swagger_ui", route.RouteTemplate, route.Defaults, route.Constraints, new BasicAuthMessageHandler(route.Handler));
I encouraged my company to use ServiceStack for one of the software projects. I am loving servicestack framework by all means. I came accross a problem that I couldn't figure out by myself.
In a web application i am using ServiceStack c# Jsonclient from a login page to authenticate. When i get authenticated c# client hold the ss-id cookies in it. So when i use same c# client for service calls i can access the session within my services.
But there is a autocomplete feature which calls a service by Jquery AJAX call the client there (browser) is not authenticated and browser does not hold ss-id cookie also.
My question is when i authenticate with c# client on code-behind. How can i store session cookies on browser (Is that needed?) so when i call service from javascript client i can access session in my services also.
Thanks for the response.
My question is when i authenticate with c# client on code-behind. How can i store session cookies on browser (Is that needed?)
So, your browser needs to have a session cookie to let ServiceStack know that it has been successfully authenticated. The browser knows nothing about what is happening with your C# clients. I'm not sure how you are posting your authentication data (username/password/etc) but if it is through a browser and you're handing the data off to a C# client you could do something like below. This is wihin MVC but the point is to get the session cookie out of the client and into the response to the browser.
public ActionResult Login()
{
var client = new JsonServiceClient("http://localhost");
var response = client.Post(new Auth() {UserName = "TestUser", Password = "Password"} );
var ssId = "";
foreach(Cookie c in client.CookieContainer.GetCookies(new Uri("http://localhost")))
{
if (c.Name == "ss-id")
{
ssId = c.Value;
}
}
var cookie = new HttpCookie("ss-id", ssId);
this.ControllerContext.HttpContext.Response.SetCookie(cookie);
return new EmptyResult();
}
If you are using MVC this would be a better way. However, I'm not sure your reasoning for using C# clients and how your are receiving the authentication data and your ability to get into the Response to the browser.
Setting both "ss-id" and "ss-pid" cookies works for me when authenticating the browser as well as the .NET client.
A somewhat rewritten part of my logon controller:
[HttpPost]
public ActionResult Logon(Auth auth)
{
using (var client = new ServiceStack.ServiceClient.Web.JsonServiceClient("://ServicestackUrl/"))
{
auth.provider = "credentials";
auth.RememberMe = true;
client.UserName = auth.UserName;
client.Password = auth.Password;
var authResponse = new AuthResponse();
try
{
authResponse = client.Send(auth);
}
catch (WebException ex)
{
throw ex;
}
foreach (Cookie c in client.CookieContainer.GetCookies(new Uri(client.BaseUri)))
{
if (c.Name == "ss-id" || c.Name == "ss-pid")
{
Response.SetCookie(new HttpCookie("ss-id", c.Value));
}
}
//Log the user on with forms authentication
string encryptedTicket = FormsAuthentication.Encrypt(
new FormsAuthenticationTicket(
1,
authResponse.UserName,
DateTime.Now,
DateTime.Now.AddMinutes(FormsAuthentication.Timeout.Minutes),
false,
""
)
);
Response.Cookies.Add(
new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket)
);
}
//Do a redirect or something
return Redirect(GetRedirectUrl);
}
I have an EJB which makes a call to another server in the cell using HTTP (REST api).
At the EJB context the user is already authenticated and authorized, how can I propagate the security tokens to the other server avoiding the need to provide credentials in the request ?
It is possible to obtain WebSphere's Ltpa token from the security subject and pass it as a cookie for the HTTP call:
public static SingleSignonToken getSSOTokenFromSubject(final Subject subject) {
if (subject == null) {
return null;
}
return AccessController.doPrivileged(new PrivilegedAction<SingleSignonToken>() {
public SingleSignonToken run() {
Set<SingleSignonToken> ssoTokens = subject.getPrivateCredentials(SingleSignonToken.class);
for (SingleSignonToken ssoToken : ssoTokens) {
if (ssoToken.getName().equals("LtpaToken")) {
return ssoToken;
}
}
return null;
}
});
}
// Get cookie to add to outgoing HTTP requests
SingleSignonToken ssoToken = getSSOTokenFromSubject(subject);
String ssoTokenStr = null;
if (ssoToken != null) {
byte[] ssoTokenBytes = ssoToken.getBytes();
ssoTokenStr = com.ibm.ws.util.Base64.encode(ssoTokenBytes);
}
String ssoTokenCookie = "LtpaToken2=" + ssoTokenStr;
By adding the ssoTokenCookie to the request cookies there is no need to provider user credentials.
Cookie ltpaCookie = WebSecurityHelper.getSSOCookieFromSSOToken();
Extracts the SSO token from the subject of current thread and builds an SSO cookie out of it for use on downstream web invocations. Basically what the whole code in the post below does. This method is accessible from WAS 8.x I believe.
Following Jar is needed as compile reference:
com.ibm.ws.admin.client-8.5.0.jar
(I'm using WAS 8.5.5.11 for this example)