3 ms·
Honestly we should have a name for such class of bugs. It's not an "I didn't know" kind of mistake. Every person sufficiently intelligent to program should figu
by RicoElectrico 3y ago
Honestly we should have a name for such class of bugs. It's not an "I didn't know" kind of mistake. Every person sufficiently intelligent to program should figure out by themselves that having 2 parser implementations can cause various undesired consequences.
- carlmr 3y agoA lot of vulnerabilities are rather obvious, but hard to avoid due to more than one person working on a project. For a sufficiently large project it's not always obvious that another implementation of something exists. And it's not always easy to search for a concept. You might use different words for it than the other person that implemented it. And even if you find it, it might have a weird badly thought out API and similar implementation, making it likely people reimplement it anyway.
- jraph 3y ago> Every person sufficiently intelligent to program should figure out by themselves that having 2 parser implementations can cause various undesired consequences. I disagree. Hindsight is 20/20, it's now obvious to me that using two different parsers for the same thing in a single process can cause bugs, but it didn't occur to me before reading about it. Now that I'm aware of this, in particular, I'll be extra careful not to parse something manually if something already does it in whatever I'm working on and there's an API for it. URLs and paths are the canonical (ah!) example of this: it's tempting to just take the string and split by "/". Whoever who has never done this should throw the first stone. And people who have never written any parser may not clearly see this stuff.
- ShowalkKama 3y ago>Honestly we should have a name for such class of bugs. They are called parser differentials