I'm trying to set up Cookie Authentication in Blazor WebAssembly, running in Chrome.
WebApp runs on https://localhost:44342
WebApi runs on https://localhost:44377
After a post request (with PostAsJsonAsync) to https://localhost:44377/user/loginuser with valid credentials, the WebApi sends back a response header with Set-Cookie: .AspNetCore.Cookies=...
That cookie seems to be rejected by the browser, because
I don't see it in F12 -> Application -> Cookies
Subsequent requests don't have the cookie attached
I researched the problem on the net extensively. I found loads of hints and explanations. Including configuring CORS, using the IP instead of localhost, setting cookie properties like SameSite, HttpOnly, Expiration and Domain or using chrome internals for further investigation.
None of that helped. Set-Cookie is still ignored by the browser.
Does anyone have a good idea on how I could proceed? Thanks
I had probably the same problem.
Chrome browser is denying the cookie ‘couse the domain is not using SSL and the cookie policy uses samesite:none.
I solved using a certificate in IIS (using HTTPS instead of HTTP). I had this problem only in production. For the development environment, when you create the project, visual studio asks if you want register a development certificate. Check yes.
I had to update a form on a certain webpage to change something i wanted.
I failed to do so, but instead of sending a simple text reply saying 'This cannot work' for example, they sent a whole JSON response on the display.
I'm just curious, does this response pose any security vulnerabilities for either me or the server i contacted to process my request?
P.S. The '***'s in the response are so because I'm not sure if providing that info is the right thing to do.
However, even without it, the response is fairly intuitive.
This is the response:
{"name":"StatusCodeError","statusCode":409,"message":"409 - [object Object]","error":{"status":"failure","message":"Email already taken.","code":91,"data":null,"error":{"message":"None"}},"options":{"uri":"*********","method":"POST","headers":{"Authorization":"Bearer *********=","Cookie":"*********=;cm_sub=denied","User-Agent":"********","Accept-Language":"en-US","Original-Accept-Language":"********","X-********-InstallId":"*****","X-*****-AppState":"active","X-*****-Parent-Rid":"********","X-*****-Root-Rid":"********","X-*****-Rid":"*****","X-Pixel-Ratio":1,"X-*****-App-Type":5,"X-Prefer-User-Locale":"1","X-Real-Ip":"********","X-*****-Real-Ip":"*****","X-*****-Csrf":"********","X-*****-Browser-Extension-Installed":"false","X-********-Referrer":"********","X-Bot":"false","X-Referrer":"********","X-Url":"********"},"form":{"base_scheme":"https","client_id":1431601,"timestamp":*****,"country":"US","email":"*****","oauth_signature":"********"},"traceId":false,"parseJson":true,"resolveWithFullResponse":true,"json":true,"simple":true},"response":{"statusCode":409,"body":{"status":"failure","message":"********","code"********,"data":null,"error":{"message":"None"}},"headers":{"server":"nginx","date":"Sun, 10 Mar 2019 16:08:31 GMT","content-type":"application/json","content-length":"112","connection":"close","*****-version":"*****","x-content-type-options":"*****","x-frame-options":"DENY","*****-generated-by":"********"},"request":{"uri":{"protocol":"http:","slashes":true,"auth":null,"host":"*****","port":"*****","hostname":"localhost","hash":null,"search":null,"query":null,"pathname********","path":"/v3/users/settings/","href":"********"},"method":"POST","headers":{"Authorization":"********","Cookie*********","User-Agent":"Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/******** Safari/537.36","Accept-Language":"en-US","Original-Accept-Language":"en-US,en;q=0.9","X-*****-InstallId":"********","X-*****-AppState":"active","X-*****-Parent-Rid":"********","X-*****-Root-Rid":"*************","X-*****-Rid":"*****","X-Pixel-Ratio":1,"X-*****-App-Type":5,"X-Prefer-User-Locale":"1","X-Real-Ip":"*****","X-*****-Real-Ip":"********","X-********-Csrf":"********","X-*****-Browser-Extension-Installed":"false","X-********-Referrer":"*************","X-Bot":"false","X-Referrer":"********","X-Url":"********","content-type":"application/x-www-form-urlencoded","accept":"application/json","content-length":179}}}}
Here's what I learned from this server response. The first thing I noticed is your protocol is using http.
"protocol":"http:"
HTTP is a plaintext and unencrypted form of communication. This is important to note because if someone is sniffing your traffic, they will be able to read the transmission as you have posted it here (without the *****'s blocking sensitive data).
The next thing I noticed is your authorization token.
"Authorization":"Bearer *********="
Given that the message is in plaintext, an attacker will be able to steal your token. Using this token an attacker can communicate with the server as an authorized user, gaining access to (and possibly the ability to modify) private information.
On the flip side, since we assume the attacker has sniffed your unencrypted traffic. They can also make note of your client's computer/ browser information:
"User-Agent":"Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/******** Safari/537.36"
From this info, the attacker can gather that the client is using windows 8.1 and what browsers/versions are installed on the client's computer. With these system specs, the attacker can launch a targeted attack on the client's computer (especially if you have an outdated/ insecure OS or browser version).
So to answer your question, yes there are security vulnerabilities for both the client and server.
However, simply switching from HTTP to HTTPS would make a big difference in limiting your exposure.
I'm running a Spring Boot application with an Angular 6 front end, on a Windows 8 server with IIS 8.5 set up as the reverse proxy (redirecting the site URL to localhost:8090) Originally I had a problem where all the PUT requests from the front end return 403, but only with Chrome and Safari, not Firefox. GET and POST requests are fine.
I am not an expert on setting up IIS, or proxy servers, by my guess is that this was because IIS was stripping out the headers that allowed CORS requests, and possibly other headers as well.
This original problem I fixed on the unsecure site, with the help of this SE: Modifying headers with IIS7 Application Request Routing
However, now the same thing is happening on the HTTPS secure site, and I don't understand what setting I should change to make this work as well.
I would also like to better understand the reason why this is failing on the secure site but not the unsecure site, and also why it fails on Chrome but not Firefox.
I'm developing a web application. During development, I want my locally hosted application can send xmlhttprequest to another domain.
I googled around, a lot of materials say to allow cors on chrome, I need to use the --disable-web-security option. Any server needs to implement the response header: Access-Control-Allow-Origin: *.
Does it mean even if a server has implemented cors, normal chrome user still won't be able to send cross origin request because the --disable-web-security is not enabled?
If that's the case, then what's the point for server to implement cors? normal user they won't know and turn on --disable-web-security option.
After did some testing, I have got my answer.
Most of the online materials or blogs are not clear about this point, you can send cross origin request by:
either has the server implement cors, i.e. the response header needs to have Access-Control-Allow-Origin: *
or you --disable-web-security your chrome browser for convenience
So you only need to have one of above for cross origin request to work. It's NOT necessary to both ensure the server implemented cors and disable web security of your web browser.
This is a maddening problem I come across once or twice every few months: websockets aren't working right. Here's the facts:
My browser can connect to my local (loopback) server, but when the browser sends messages, the server never gets them.
This has happened a few times to me before in the last 6 months - it always seems to start working without any change on my end, and for no apparent reason
This started happening right after I restarted my computer...
http://www.websocket.org/echo.html also doesn't work
The connection is being closed with code 1006, wasClean is false, and reason is a blank string
Firefox and chrome both have this problem
I've confirmed that turning off my firewall (windows 7) doesn't change anything
I've also confirmed that a node.js client and server works on linux (centos 6 VM running inside my windows machine), but the same client and server setup doesn't work on my windows machine (tho when I tested on a different windows 7 machine, it works fine)
Here's the info from chrome's network tab:
Request URL:ws://echo.websocket.org/?encoding=text
Request Method:GET
Status Code:101 Web Socket Protocol Handshake
Request Headers CAUTION: Provisional headers are shown.
Cache-Control:no-cache
Connection:Upgrade
Cookie:__utma=9925811.1690403310.1402691326.1402691326.1402691326.1; __utmb=9925811.13.10.1402691326; __utmc=9925811; __utmz=9925811.1402691326.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided)
Host:echo.websocket.org
Origin:http://www.websocket.org
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits, x-webkit-deflate-frame
Sec-WebSocket-Key:eH9OcxKQ/I6S+IkzY+HsaA==
Sec-WebSocket-Version:13
Upgrade:websocket
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36
Query String Parametersview sourceview URL encoded
encoding:text
Response Headers
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:x-websocket-protocol
Access-Control-Allow-Headers:x-websocket-version
Access-Control-Allow-Headers:x-websocket-extensions
Access-Control-Allow-Headers:authorization
Access-Control-Allow-Headers:content-type
Access-Control-Allow-Origin:http://www.websocket.org
Connection:Upgrade
Date:Fri, 13 Jun 2014 21:36:59 GMT
Sec-WebSocket-Accept:d0eOTUUxMpkKsI6x9RJ+vGBxl3w=
Server:Kaazing Gateway
Upgrade:WebSocket
Is there something that looks wrong in those headers? Anyone have any idea what might be going on? Its like my computer is blocking websocket messages but not connections.
UPDATE:
Unbelievable. I literally have taken no action to correct this. I haven't restarted, changed settings, or installed or uninstalled anything. But the problem is gone - messages now go through as normal. Why is this happening?
Try to enable WebSocket Protocol.
Go to :
Control Panel -> Program and fonctionality -> Enable or disable windows features