16
kiki
3y

Seriously, y'all shitting on CORS but why? literally, why? it protects you. If you need an external api, could you please be fucking bothered to setup redirects, so it's /api and not fucking https://amazon23984723984723984.aws239847329847230948.spyware/...? duh

people who allow cors from "*" are the same people who always do everything with superuser rights. you're the reason why I always got offers

Comments
  • 0
    God I hate you all lol
  • 3
    If I make an API for others to use, I want it to be accessible from every computer and every website, so it's *. If I make a private API I don't set up CORS and just proxy /api.
    If I make an API for a configurable particular website (think rental cloud services) I make allow-origin configurable.
  • 0
    who's shitting on CORS?
  • 1
    @homo-lorens is above 98% of y’all boubas
  • 0
    @homo-lorens proxy api seems the nest route anyway

    You don’t have to mess with Cors
    If you just forward the api parameters through a backend on the same server to the external api and retrieve and forward the results
  • 4
    @killames please.

    Take your keyboard, hit yourself repeatedly until you never ever think of sth like that again.

    A proxy shouldn't be misused - and especially not seen as a security measure or anything like that...

    CORS belongs - as it should always be application specific - in the applications webserver, not somewhere else.

    A proxy should be transparent in case of reverse proxying - I know a lot of people who try to turn an proxy into a kind of proxy firewall / API gateway / <we didn't bother so we just rewrote everything somewhere in the proxy> stuff...

    And it's bad. A proxy (e.g. h2c smuggling) is vulnerable and the more the proxy does, the more likely the performance and security of your application suffers. Not to mention deployment pains, as without the proxy your application might not even work at all and without access to the proxy config no one might even know why.

    A proxy is *not* the place to fix stuff you borked up in an application.
  • 0
    @IntrusionCM personally I just hate http lol
  • 0
    @IntrusionCM and yeah I get it
    And technically you’re also doing half the work of the sever and blah blah it’s easy enough to add the header allowing the origin on the service the browser is connecting to

    And yes that was a knee jerk reaction to my hatred of cors

    Which sucks
    And prevents me from testing Ajax calls from goddamn html files
    Which used to be a bigger deal
  • 1
    @IntrusionCM such violence! Lol
  • 2
    Isn't cors a browserside thing?

    Meaning that curling the source just gets it anyways?
  • 0
    @nitwhiz yeAh

    The server tells the browser how to handle cross origin script includes

    Meaning if a page on yahoo

    References a script on crapdevmethods

    The response header of the original page has to include an allow-origin for that domain and then the browser will behave itself and load the script

    I was testing a ja script api with a static html page on my machine when I first encountered this stupid shit
  • 0
    @IntrusionCM am I wrong with the description ? Want to hit me some more ?
  • 1
    @killames I never hit you.

    :)

    https://upload.wikimedia.org/wikipe...

    CORS is a browser standard that allows the server / JS client runtime to define who has access and what can be executed.

    It is a browser "gentleman" agreement - the browser asks nicely the server via an OPTION request (preflight) wether the request can be executed.

    "Request can be executed" meaning if the HTTP method and domain are allowed to be executed.

    In a nutshell, when you include an foreign script... And that script tries to call 'back'.... The browser and CORS prevents the script from doing nasty stuff.

    JS is client side - the script cannot execute any requests if your server forbids it if it runs in a browser.

    (CORS is of course useless if the HTTP library doesn't support it / implement it - but that's an whole different thing and _could_ be enforced on server side, e.g. sticky tables... But that's another story as non standard library opens a whole can of other attack vectors)
  • 0
    @IntrusionCM just amuses me I designed and wrote a whole web app and never encountered that bs as all our data was housed on site and all our Api calls under the same domain and when I do there was no good docs on how to prevent it in my specific scenario
  • 1
    @killames well.... Don't take it personally, but the "Dunno don't care" principle is strong in every company.

    Security and education costs.

    Hence it are the two things that are obviously cut / ignored "for financial reasons".

    In every company I worked so far were severe security holes. Usually they were lucky noone pressed charges....

    On the other hand - the law loves the term "deliberately" / "vorsätzlich" (German)... So If you at least _try_ to put up the easy stuff like CORS, you / the company might get lucky when someone presses charges.

    And pressing charges "for profit" will become more and more attractive I guess.

    In Germany we at least have an employee protection by law, in countries like the USA you might get fired so the company "gets away with it" and you'll never get a job again.
  • 0
    @killames why not use a WAF at that point?
  • 0
    @sariel no what I’m saying is the use of cors had no point on our intranet app

    So I simply just never saw the error until doing something on my own time

    What’s a waf again ? Lol
  • 0
    @IntrusionCM you know I’ve seen some of the evolution of web security and it’s all pretty laughable to me

    I could browse to a webpage and get a browser hijack installed

    So saying “oh yeah you can run any script from this domain or no script from any other domain or a script that does this kind of request or that kind of request” seems pretty moot

    Just a while ago I was browsing Pinterest for a web paper and my sec software warned me of a hijack attempt
    Point is we base all this around a central insecure point which does not guarantee security at all
  • 0
    @killames internal or not. Sometimes internal teams have the best of intentions and take your API down when they throw 60k requests per second at it.

    WAF is Web Application Firewall.

    Use it when you want to control every piece of a network request.

    It can redirect, reject, transpose, rewrite, and hijack any web request. I believe some can even scan layer 3 network communications.
  • 0
    @sariel sounds interesting
  • 0
    @sariel I once saw someone put a firewall between the two sides of a vpn

    It was misconfigured and caused sql connections to drop resulting in an application on the same network bombing on numerous workstations

    I don’t like adding more working parts
  • 0
    The only real issues with CORS I've seen stem from crap messing with http headers and crap is out of the developers control.

    But some other issues also arise from that same lack of control. CORS just happens to be a frequent flyer that is out of the Devs run into early on.
Add Comment