4 ms·

> The attack depends on multiple software products all making very reasonable decisions about how they should work, but the way they interact with each other le

> The attack depends on multiple software products all making very reasonable decisions about how they should work, but the way they interact with each other leads to a vulnerability. I'm sorry, but I disagree. A browser allowing externally loaded scripts to access private ip ranges is not a reasonable decision. PSA: To protect yourself from this, and some more bad browser defaults, use NoScript with "allow all scripts globally." Keep the JS, but filter out some bad stuff. Also enable ABE (application boundaries enforcer, made to solve exactly this problem) for good measure.

hueving 10y ago
>A browser allowing externally loaded scripts to access private ip ranges is not a reasonable decision. So you think a browser should pin IP addresses to DNS names and not follow DNS updates? That's what you're implying.
- reissbaker 10y ago
  No. What the parent is saying is that: if the script was loaded from an external IP address, it should be blocked from talking to an internal IP address. The browser knows whether it loaded a script from an external IP address, and it knows what the internal IP addresses are, so it can just ban something loaded from elsewhere from talking to ports on your local machine.
CWuestefeld 10y ago
A browser allowing externally loaded scripts to access private ip ranges There are plenty of legitimate systems in the ecommerce world that rely on doing this. Take Ariba Punchout, for example. The idea is for the store to pass the user's shopping cart back into the customer's internal ERP system to be turned into a purchase order and sent for approval. The way this is handled is that the initial request sets up a session including a URL to a customer-internal service that's intended to handle the transaction. When the user completes checkout, a page is returned to the user containing an XML payload, and script to submit that XML to the specified internal service URL. That way, the store is able to provide the PO data to what is otherwise a completely internal system.
- nothrabannosir 10y ago
  Which can all be handled using an (automated) whitelist, à la CORS. Too many things run on localhost (or intranet) and assume that localhost=safe. I know, "that's wrong" and "don't listen on 127.0.0.1" and all that, but that horse has left the barn, emigrated, founded a family and died happy. We can't put the 127/192/10 genie back in the bottle. Prevent access to all private resources from the outside and whitelist on a need-to-access basis. Or be ready to keep monkey patching your system against these exploits forever.

hueving 10y ago

>A browser allowing externally loaded scripts to access private ip ranges is not a reasonable decision. So you think a browser should pin IP addresses to DNS names and not follow DNS updates? That's what you're implying.

reissbaker 10y ago
No. What the parent is saying is that: if the script was loaded from an external IP address, it should be blocked from talking to an internal IP address. The browser knows whether it loaded a script from an external IP address, and it knows what the internal IP addresses are, so it can just ban something loaded from elsewhere from talking to ports on your local machine.

CWuestefeld 10y ago

A browser allowing externally loaded scripts to access private ip ranges There are plenty of legitimate systems in the ecommerce world that rely on doing this. Take Ariba Punchout, for example. The idea is for the store to pass the user's shopping cart back into the customer's internal ERP system to be turned into a purchase order and sent for approval. The way this is handled is that the initial request sets up a session including a URL to a customer-internal service that's intended to handle the transaction. When the user completes checkout, a page is returned to the user containing an XML payload, and script to submit that XML to the specified internal service URL. That way, the store is able to provide the PO data to what is otherwise a completely internal system.

nothrabannosir 10y ago
Which can all be handled using an (automated) whitelist, à la CORS. Too many things run on localhost (or intranet) and assume that localhost=safe. I know, "that's wrong" and "don't listen on 127.0.0.1" and all that, but that horse has left the barn, emigrated, founded a family and died happy. We can't put the 127/192/10 genie back in the bottle. Prevent access to all private resources from the outside and whitelist on a need-to-access basis. Or be ready to keep monkey patching your system against these exploits forever.