6 ms·

I'm ideologically against third party on the web because it is a privacy nightmare. But I'm in the system that I'm in, and I don't take on fights that aren't po

• paulddraper 8y ago
  CORS is not necessarily about third parties. It's common to have app.example.org point to a CDN and api.example.org point to an API. And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself. The reason it's implemented this way is because of the organic evolution of web security.
  • ravenstine 8y ago
    > rather than just enforcing access itself. Could you elaborate on that? I can't picture the alternative you're suggesting.
    • icebraining 8y ago
      Same here... from what I can tell, only the browser has reliable information about what's happening. How could the server know code from another domain is making the requests? And if anything, the web is more secure - desktop native applications can usually access each other's data and do malicious requests to remote servers using stolen credentials just fine.
      • johncolanduoni 8y ago
        Via the Origin header, just like the preflight requests use. The server is ultimately the one telling the browser what the rules are already. The reason a preflight is needed is so that there is effectively a default deny policy, since both historically and even today you can’t assume all APIs that accept authentication tokens from the browser take into account any kind of cross origin access. Even still, a lot of people just put ‘Access-Control-Allow-Origin: *’ on everything as soon as they run into an issue, so that rule has to ban credentialed requests altogether.
        • sbergot 8y ago
          You are talking about the Origin header set by the browser that you don't trust?
          • johncolanduoni 8y ago
            The whole point of CORS is that you trust the browser to do the preflight requests and obey them, otherwise it doesn’t do anything. If you have access to the credentials (which the browser does) and the ability to send whatever HTTP requests you want, you can bypass CORS entirely.
    • nothrabannosir 8y ago
      Using HMAC or API keys.
    • paulddraper 8y ago
      The alternative is for the idea agent to send the Origin header on all requests. Then the server responds with 200 or 403.
      • rnotaro 8y ago
        The origin could still be falsified client-side.
        • jacobparker 8y ago
          No, it can't be falsified by JS in the browser. CORS is only relevant for JS in the browser; it doesn't impact curl at all, for example.
        • ubernostrum 8y ago
          This is kind of like the reports I see every so often to Django's security address, where someone demonstrates that they can CSRF their own session. The reply is always "yes, you can CSRF yourself, because it's not supposed to protect against that; it's supposed to protect you from other people". In exactly the same way, CORS is there to protect you from other people. You can always hack your own user-agent to disregard CORS, but the only person you can harm that way is yourself.
      • deleted 8y ago
        [deleted]
      • mattnewton 8y ago
        The people with the security problem are the users of browsers, and the browser vendors have a solution to solve that problem built into the browser. If they didn’t enforce it at the browser level, the owners of the servers would have little incentive to enforce CORS and most just wouldn’t. See https adoption.
        • johncolanduoni 8y ago
          Bingo. I still kind of wish there was an ability to make the browser invoke some kind of request that servers would reject by default (e.g. with a non-standard HTTP method) that could combine the preflight check and the request while still making servers that don’t anticipate CORS blanch and not take any dangerous actions. But the browser security model is complex and messy enough as it is, so I doubt it’s worth it.
  • inopinatus 8y ago
    CORS protects users, not services, so it's entirely reasonable that the evaluation of policy occurs in the user agent.
    • bzbarsky 8y ago
      Actually, CORS protects both. If CORS aimed to only protect users, there would be no need for a preflight at all. The only reason preflights exist is to protect services from receiving requests they might really not expect (e.g. malformed data) and doing bad things as a result. In particular, the idea is to protect non-publicly-routable services. Publicly-routable ones, where you can just issue an attack request with cURL or the like, have to be hardened against malformed requests to start with. But there are tons of non-publicly-routable things (think printers and the like behind firewalls) that could be attacked via browsers that are running behind the firewall loading web pages from outside the firewall. And CORS aims to mitigate or prevent some of those attacks.
  • aikah 8y ago
    > And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself. The only concerns of CORS is with Javascript running in the browser. CORS is not about server-side security but what Javascript can or cannot access. It is there to protect the browser's user and make script execution more secure.
  • notyourday 8y ago
    > And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself. That's a typical misunderstanding of purpose of CORS. Regardless of your website setting or not setting CORS, an attacker with a modified browser or a custom browser can ignore it. That's not what CORS protects from - CORS protects against a non-modified browser uased by Joe Random User installed via a factory/distribution path being tricked into doing something against the site policy, therefore exposing the user.
    • paulddraper 8y ago
      I don't misunderstand. My beef with CORS is that I have to encoded the validation logic into its HTTP headers. But maybe what I want doesn't fit in its headers, e.g. I want to allow requests from *.example.org. So then I am writing server code, and if I am writing server code anyway, why have the extra step of encoding validation logic in CORS headers in the first place?
      • sbergot 8y ago
        Surely you can implement your security rules this way. But for most people CORS are a cheaper way to enable cross origin requests. And clueless people are stuck with same origin policy which secure by default.
        • paulddraper 8y ago
          > CORS are a cheaper way to enable cross origin requests Is it really that much more expensive to check the Origin header than to check the Authorization and Cookie headers?
          • ec109685 8y ago
            If your server can handle Origin checks that way, then leave your CORS headers wide open and problem solved. The problem is that existing servers don’t generally check origin headers, so browsers needed some other mechansim to understand which requests were safe.
  • Ajedi32 8y ago
    > And CORS implementation is terrible. The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself. I disagree. The current model where the server has to opt-in to cross origin access by explicitly sending an Access-Control-Allow-Origin header is secure-by-default, whereas a model relying on the server to enforce access would be insecure-unless-the-server-properly-checks-the-origin-header, leading to all sorts of vulnerabilities.
    • paulddraper 8y ago
      It's already insecure-unless-the-server-checks-the-cookie-header.
      • ec109685 8y ago
        Something servers already do.
    • biot 8y ago
      It’s secure in a “trust the client” manner. Any server code not still doing its own authentication is in for a rude awakening.
      • ec109685 8y ago
        If you don’t trust the client, there is nothing you can do. An insecure browser could spoof the origin header too.
        • biot 8y ago
          I think you’re missing my point. While you can assume well behaved clients will reduce unwanted traffic, a malicious client will spoof everything it can. Thus, there is definitely something you can do: you should never trust the client and the server should authenticate every request (as if CORS didn’t exist) instead of assuming all requests from clients are valid.
  • Boulth 8y ago
    > The server has to transmit validation rules for the browser to enforce (with vendor specific caching differences), rather than just enforcing access itself. That's not true. You can set CORS: * and validate all requests in your server. The extra rules are for vast majority of servers that never inspect Origin headers.
  • int0x80 8y ago
    Exaclty. This is a big concern for me. The server is really telling the browser what to do. But the browser can ignore it. It is quite a hacky an inellegant model. Very broken.
    • sbergot 8y ago
      CORS are about browser security. A browser can have terrible security in lots of ways (allowing JavaScript to access http only cookies, etc). In this case you have a bad browser and you should not use it. But you can still use IE, edge, chrome and Safari and trust that they implement CORS and most other basic security features correctly.
• matchagaucho 8y ago
  Our microservices stack is pretty dependent upon clients making cross-origin requests. I don't necessarily consider these "3rd party".
  • latch 8y ago
    Case by case basis, but it's not uncommon to have clients hit a single domain and route the traffic based on the url. Exposing a microservice architecture to clients has pros and cons, of which this is a con.
  • emilsedgh 8y ago
    That would mean each call made by the client would require a preflight OPTIONS call. That means extra delay, extra db connections and calls, etc. How do you deal with them?
    • matchagaucho 8y ago
      Pre-flight overhead, yes (maybe 30ms?) DB connections are pooled and cached using AWS Lambda. btw- Our app is a plugin, so origin is always the platform provider... then our app makes CORS calls to AWS.