• 0 Posts
  • 702 Comments
Joined 2 年前
cake
Cake day: 2023年6月21日

help-circle





  • Any website using CSR only can’t have a RCE because the code runs on the client. Any code capable of RSC that runs server and client side may be vulnerable.

    From what I’ve seen, the exploit is a special request from a client that functionally lets you exec anything you want (via Function’s constructor). If your server is unpatched and recognizes the request, it may be (likely is) vulnerable.

    I’m sure we’ll get more details over time and tools to manually check if a site is compromised.




  • I think their point was that CSR-only sites would be unaffected, which should be true. Exploiting it on a static site, for example, couldn’t be RCE because the untrusted code is only being executed on the client side (and therefore is not remote).

    Now, most people use, or at least are recommended to use, SSR/RSC these days. Many frameworks make SSR enabled by default. But using raw React with no Next.js, react-router, etc. to create a client-side only site does likely protect you from this vulnerability.


  • I think it also doesn’t help that only 4XX (client error) and 5XX (server error) are defined as error status codes, and 4XX errors don’t even necessarily indicate that anything happened that shouldn’t happen (need to reauth, need to wait a bit, post no longer exists, etc).

    Trying to think of what 6XX would stand for, and we already have “Service Unavailable” and “Bad Gateway”/“Gateway Timeout”, so I guess 6XX would be “incompetence errors”. 600 is “Bad Implementation”, 601 is “Service Hosted On Azure”, 602 is “Inference Failure” (for AI stuff), and I guess 666 is “Cloudflare Outage”.







  • 30 is assuming you write code for all 30 days. In practice, it’s closer to 20, so 75 tests per day. It’s doable on some days for sure (if we include parameterized tests), but I don’t strictly write code everyday either.

    Still, I agree with them that you generally want to write a lot of tests, but volume is less important than quality and thoroughness. The author using the volume alone as a meaningful metric is nonsense.





  • Quoting Kohler:

    We encrypt data end-to-end in transit, as it travels between users’ devices and our systems, where it is decrypted and processed to provide and improve our service.

    I guess Kohler recently learned about TLS? IBM’s response, which is a bit random in my opinion, addresses the idiocy of the E2EE claim lol.

    I’d hope they encrypt data in transit? Not doing so would be an incredible, though unsurprising, show of incompetence. Setting up TLS and getting certs is easy these days with LetsEncrypt, and a company like Kohler could even get certs through AWS or Azure or something if they wanted.

    I can’t imagine why I’d ever spend money on a camera for my toilet, especially if it includes a subscription fee. That’s a new level of stupid.