* You have a restricted shell or other way to execute a restricted set of commands or binaries, often with arbitrary parameters. You can use GTFOBins in interesting ways to read files, write files, or even execute commands and ultimately break out of your restricted context into a shell.

* Someone allowed sudo access or set the SUID bit on a GTFOBin. Using these tricks, you may be able to read or write sensitive files or execute privileged commands in a way the person configuring sudo did not know about.

Assuming something similar to Sentry would be in use, it should clearly pick up the many process crashes that start occurring right as the downtime starts. And the well defined clean crashes should in theory also stand out against all the random errors that start occuring all over the system as it begins to go down, precisely because it's always failing at the exact same point.

In practice, SameSite=Lax is already very effective in preventing _most_ CSRF attacks. However, I 100% agree with you that adding a second defense mechanism (such as the Sec header, a custom "Protect-Me-From-Csrf: true" header, or if you have a really sensitive use case, cryptographically secure CSRF tokens) is a very good idea.

You do need a rigid authentication and authorization scheme just as you described. However, this is completely orthogonal to CSRF issues. Some authentication schemes (such as bearer tokens in the authorization header) are not susceptible to CSRF, some are (such as cookies). The reason for that is just how they are implemented in browsers.

I don't mean to be rude, but I urge you to follow the recommendation of the other commenters and read up on what CSRF is and why it is not the same issue as authentication in general.

Clearly knowledgeable people not knowing about the intricacies of (web) security is actually an issue that comes up a lot in my pentesting when I try to explain issues to customers or their developers. While they often know a lot about programming or technology, they frequently don't know enough about (web) security to conceptualize the attack vector, even after we explain it. Web security is a little special because of lots of little details in browser behavior. You truly need to engage your suspension of disbelief sometimes and just accept how things are to navigate that space. And on top of that, things tend to change a lot over the years.

SameSite=Lax (default for legacy sites in Chrome) will protect you against POST-based CSRF.

SameSite=Strict will also protect against GET-based CSRF (which shouldn't really exist as GET is not a safe method that should be allowed to trigger state changes, but in practice some applications do it). It does, however, also make it so users clicking a link to your page might not be logged in once they arrive unless you implement other measures.

In practice, SameSite=Lax is appropriate and just works for most sites. A notable exception are POST-based SAML SSO flows, which might require a SameSite=None cookie just for the login flow.

The gist of it:

> The publisher account for Material Theme and Material Theme Icons (Equinusocio) was mistakenly flagged and has now been restored.

Previous discussion here, which is also the reason why I think this resolution is relevant as well: https://news.ycombinator.com/item?id=43178831

Comments URL: https://news.ycombinator.com/item?id=43347421

Points: 6

# Comments: 2

As the references show, this is already a big source of vulnerabilities - trying to push for a change in standards would likely make the situation much worse. At the very least, old unmaintained servers will not change their behavior.

I think we should accept that this ship has sailed and leave existing protocols alone. Mandate LF and disallow CRLF in new protocols, that's fine, but I don't think we should open this particular Pandora's Box.

[1] Simple example that doesn't use CRLF/LF disagreement: https://portswigger.net/web-security/request-smuggling

[2] Complex example that uses CRLF/LF disagreement: https://portswigger.net/web-security/request-smuggling/advan... (see heading 'Request smuggling via CRLF injection')

[3] Random report on HackerOne I found where allowing LF created a vulnerability in NodeJS: https://hackerone.com/reports/2001873

[4] https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-...

I took a very basic course about gate-model quantum computing at my university. The (mathematics) professor would have loved to be able to explain adiabatic quantum computing on a basic level, but was unable to find entry-level material to really understand how it works or what problems it can solve.

> Notice how state was introduced? It made the code easier to read.

Correct me if I'm wrong, but the only state in that snippet lives in Stream.iterate(), the Fibonacci object is still immutable and next() on it is a pure function. To me this still looks very much like a functional programming approach.

Which just shows that moving business logic into properly named abstractions is good, no matter the programming paradigm.

The real stateful example is the IncrementSupplier and the impure get() method. I personally don't really like it ( Stream.iterate(0, i -> i + 1) is pretty readable to me), but that's probably just personal taste.

I'll definitely try it out!

They banned these devices because they are essentially bugs/covert listening devices and are even marketed as such. Devices that look innocious (such as children's watches or teddy bears) but in reality are covert listening devices are banned in Germany by §90 TKG. [1]

This is why the Bundesnetzagentur banned the smartwatches in question. They even cited cases in which these watches were used to monitor teachers in classrooms. [2]

"Normal" smartwatches are NOT banned. "Normal" smartwatches for children are also NOT banned. Only watches with monitoring functions fall under the §90 TKG law. [3] Note that using an app to bring covert listening functionality to a phone or watch also converts that device into an illegal listening device.

[1] https://www.gesetze-im-internet.de/tkg_2004/__90.html (Just for reference)

[2] https://www.bundesnetzagentur.de/SharedDocs/Pressemitteilung... (German, but google translate works sufficiently well)

[3] https://www.bundesnetzagentur.de/DE/Sachgebiete/Telekommunik... (German, use a translator)