91–100 of 148 posts
I never understood why websockets aren’t subject to same origin policy and CORS (or similar policies). Any web expert here could explain this design (non-)decision?
eBay has a big fraud headache. They have a bunch of algorithms (from the pre-ML-hype days) that take a variety of inputs to determine whether a given transaction is fraudulent or not. Presence of remote login service on the user’s computer may tip the scale heavily in this calculation. Fraud detection is a necessary evil for all financial transaction companies in order to keep costs low for everyone else. If you’re w…
That doesn't mean they should be allowed to behave like cybercriminals. The risk of fraud doesn't give them a free pass to abuse our trust and invade our privacy. They aren't entitled to know what software people run on their own computers. Especially if they learn this information through underhanded means like port scanning people's local networks without their permission or knowledge. It doesn't matter how much money they're losing because of fraud, they don't get to violate these boundaries in order to reduce the risk associated with their own business.
I never understood why websockets aren’t subject to same origin policy and CORS (or similar policies). Any web expert here could explain this design (non-)decision?
Browsers set the "Origin" header for ws:// calls, and the websocket servers are expected to check that. Without the check, it'd be possible to issue blind writes (CSRF) from random webpages to the ws:// endpoints. If you're using main site authentication with a separate websocket domain and auth'd requests, all garden variety security scanners will flag the separate websocket domain as a problem, and only the robust ones actually try to validate the server side configuration.
Disclosure: I have triaged and responded to a few of such reports.
This feels more effective and less intrusive. Not sure why ebay went this rather weird and creepy way instead.
Google's internal sso (which I accidentally stumbled upon) collects other endpoint-specific parameters to compose the digital signature (like browser window size and monitor size). This feels more effective and less intrusive. Not sure why ebay went this rather weird and creepy way instead.
They may not even be using it actively yet because they'd need to gather a lot of example data to detect outliers.
I asked this earlier and nobody had a response, so thought I'd ask it again: is there an extension to block this? Edit: @Windows users: pip install pydivert and then try to write a script to block connections from Chrome to non-Chrome processes. you might need GetTcpTable2() or something. (Looking into this now. Check out http://stackoverflow.com/a/25431340 )
I never understood why websockets aren’t subject to same origin policy and CORS (or similar policies). Any web expert here could explain this design (non-)decision?
Websockets are subject to the same origin policy. There's nothing you can do to violate the SOP via websockets that you wouldn't be able to do with regular HTTP or XHR.
index.html:
let ws = new WebSocket("ws://localhost:5000/");
ws.onopen = () => ws.send("hello server!");
ws.onmessage = ev => {
const $message = document.getElementById("message");
$message.textContent = `ws://localhost:5000/ response: ${ev.data}`;
};
const express = require("express");
const http = require("http");
const WebSocket = require("ws");
const app = express();
const server = http.createServer(app);
const wss = new WebSocket.Server({ server });
wss.on("connection", ws => {
ws.on("message", message => {
console.log(`received: ${message}`);
ws.send("hello client");
});
});
server.listen(5000, () => console.log("ws server listening on localhost:5000"));
I never understood why websockets aren’t subject to same origin policy and CORS (or similar policies). Any web expert here could explain this design (non-)decision?
Surprisingly often websocket connections are made to a different domain from what is serving the site itself. I'm not sure about the root cause to the pattern, but sure as hell know that our company has been doing it at least since 2013. Browsers set the "Origin" header for ws:// calls, and the websocket servers are expected to check that. Without the check, it'd be possible to issue blind writes (CSRF) from random w…
> Browsers set the "Origin" header for ws:// calls, and the websocket servers are expected to check that.
I know that, but as always insecure by default protocols are terrible, and are guaranteed to be exploited beyond recognition... The question is why not be secure by default and force servers to whitelist origins they expect to talk to?
Earlier quoted context omitted.
As far as I know these port scans are done using WebRTC. Using a browser extension[0] it is easy to deactivate it on the go. Personally, I always have WebRTC disabled by default (as it has several nasty security implications), and only activate it if I explicitly need it for something. [0] https://addons.mozilla.org/en-US/firefox/addon/happy-bonobo-...
This is the kind of thing the webkit team at apple raised as privacy problems with webrtc. They got called IE. But seriously, many new specs are very obviously abusable, yet on HN people seem unwilling to accept "this feature is trivially abusable" as a reason to not give developers a new feature, even when it is user hostile. Web specs, and the webdevs he frequently want them, need to consider abusive developers bei…