"engineers tidied up [..] their source code, and [..] reintroduced the exploitable bug"
So, they "tidied up", but did not test.
Or, at the very least, did not test against proven vulns.
Coding is not always easy, but this seems slightly sloppy.
A security flaw in Apple's Safari web browser that was patched nine years ago was exploited in the wild again some months ago – a perfect example of a "zombie" vulnerability. That's a bug that's been patched, but for whatever reason can be abused all over again on up-to-date systems and devices – or a bug closely related to a …
Well it took Apple many years to admit that MACstuff can actually get a virus. Now they are admitting that it takes them years to reintroduce a virus that MAC Users couldn't get.
The future sure isn't rosey, unless that's from the glow of burning software houses...........
Single page webapps often want to add new entries to the history to allow people to go back to a previous page without actually loading a new page.
There's an argument for not allowing replacing an existing state, but that could be emulated by removing and adding a new state anyway so there's no harm in having it.
Kind of makes "forensics" a problem, yes?
To allow modification of browser "history" is to invite all sorts of mischief when a malicious individual, group, or Government, decides to fabricate or enhance a potential case against someone.
From the Mozilla docs - https://developer.mozilla.org/en-US/docs/Web/API/History/pushState
"The new history entry's URL is given by this parameter. Note that the browser won't attempt to load this URL after a call to pushState(), but it might attempt to load the URL later, for instance after the user restarts the browser. The new URL does not need to be absolute; if it's relative, it's resolved relative to the current URL. The new URL must be of the same origin as the current URL; otherwise, pushState() will throw an exception. If this parameter isn't specified, it's set to the document's current URL."
Note that the URL has to be the same origin, so you can't inject the URL for some illegal site into the history unless the user was already on that site (and then there's no framing required).
"She noted that developers in 2013 patched all the different paths that triggered the vulnerability, not only the one in proof-of-concept exploit code that was submitted at the time to prove a flaw existed. However, the refactoring done in December 2016 revived the vulnerability."
/* Here be dragons. We put in all this cruft to protect against all the ways such-and-such CVE could be exploited. __Do not remove this code without complete testing.__ */
Of course the critical code *will* still be removed in refactoring. Q: "What's all this? It's too complicated, I don't understand it." A: "Dunno. I don't understand it either, just get rid of it. Simpler is better." But at least then the old comments will show up in the diff, which hopefully the team lead is reviewing.
Biting the hand that feeds IT © 1998–2022