Imagine pwning a frontend server or proxy, spawning an http/s server on another port, and being able to intercept all cookies and sessions of all users, even when you couldn't pwn the (fortified) database.
This could have a huge advantage, because if you leave the original service untouched on port 80/443, there is no alert popping up on the defending blueteam side.
Before reading this, I assumed the method would involve rewriting large parts of the game's graphics code. But it sounds like the author is intercepting draw calls and changing them to use color instead! Looking forward to the rest of this series.
I was bracing myself for another "don't support Linux because packaging is a mess" post, but was pleasantly surprised. Only 3 of the Linux reported bugs were Linux-specific - all the others were real cross-platform bugs affecting everyone. Free QA, indeed.
Keep in mind that the website author has the ability to delete content from archive.org (and I've seen a pretty significant website for a community I'm a part of do so when it shut down, ostensibly for "GDPR compliance" reasons.)
All it takes is a robot.txt file with the right entries in it.
We need something like archive.org, but which reflects the wishes of historians and preservationists, not paranoid website owners.
Do we need that? I feel like the right to be forgotten needs to be protected too. I’m already uncomfortable with the extent to which everything I write can live forever
> It's on my to-do list to automatically mirror all HN submissions as well
I recently emailed that suggestion to dang as well - both Web Archive and Archive Today (aka archive.is/ws/ph/wh/whatever), as the former is more likely to stick around and the latter is better than 12ft at bypassing paywalls. It's on their to-do list as well.
I'm a huge side project procrastinator, but if this comes after HN performance improvements on dang's to-do list I feel like I might beat them to it ;)
Previously I worked on an open source project that pulled in many third party libraries. Users would run their corpo vulnerability scanners on the project and find dependencies with open CVEs and demand fixes, not understanding that in our usage of the libraries, the vulnerability is not exposed.
I think in 4 years, we had users open roughly 50 issues like this, which corresponded to exactly 0 real world exploitable issues.
A central vuln DB makes sense for sysadmins, but too many make it the end-all-be-all.
I think this ends up devolving to Goodhart’s law: once CVEs became marketing, a ton of people had a huge incentive to game their stats at the expense of everyone else’s time.
reply