So after the recent incident with XSSTC-vulnerable bbcode on the forums (this, which is now fortunately fixed thanks to @Alley, so I can talk about it) I really have to ask what precautions are done in the way of forum information security.
I have been here for just over two years now and on two separate occasions I've witnessed flaws that could have brought the forums down entirely and the only reason they didn't is because in both cases there was a responsible person (the same in both instances) on the hotline that could fix them.
The first one was the infamous forum rollback, during which there even were questions flying around about a possible restart of the entire Discovery if no backups were found (and as far as I understand they were found only because Alley had some laying around by chance), the second one was the aforementioned XSS vulnerability which was open to attack for about two months (and if you don't believe me, have a read: this and this should give you an idea).
So now, we have people in the community that are versed with web development ( @Alley is god, @Error coded the navmap, yours truly has administrated two long-lasting MyBB boards for a while) so why is stuff done even without going through those people? Some of this is potentially destructive if you don't know what you're doing.
The forum rollback was pretty bad and didn't only affect the forums. I still remember that day. On the very same day the server died, I was performing a firmware update on a first-gen SSD and it decided it wouldn't work and permanently died. How fun it was (it wasn't) when I got windows installed on my second SSD to find Disco in a vegetative state and my skype completely bombarded. The twitter account saved our ass here, we also had some fun on the temporary IRC despite all. It's true we were lucky I had a backup of the virtual machine, if I didn't I guess the community would be dead by now with everything ever done on the forums gone.
It was a good lesson though, backups of the SQL are regularly made (that's something I guess) and when I can get around buying these two 2tb drives to RAID them I'll start doing regular full backups of the VMs.
Aside of that, the title is maybe a little overdramatic. The flaw was pretty bad, that's true, however the possible damage through it was still limited. At best you could have replaced all images with cats or some other minor page-limited annoyances (or put some code that render the body in display:none lolol). That doesn't forgive it, regex and sanitization are specifically here to prevent these things from being possible and they should be used. I guess it doesn't help when mybb itself doesn't sanitize much when it comes to posts.
We actually did indirectly suffer a real XSS attack once, maybe you remember that hour where every forum page was replaced with that huge you've been hacked text. That wasn't even meant for us, some pretty clever guys wanted to target some political website and as they couldn't get access to it they somehow managed to compromise another website we too were using at the time that proposed a script to detect outdated browsers like IE6 and display a popup to prompt the user to upgrade. They compromised that script and their message ended up on hundreds of websites, including ours. This too was a good lesson, these days we are a bit too used to all these cool next-gen CDN, but what if they get compromised?
I personally don't have time to handle everything and be everywhere, so if you want to take a look at the current mycodes and ensure the regex are all properly written, you're more than welcome.
Wait, what? I noticed and reported exactly the same issue when [hr=<colour>] was first released on the tenth of March. I'm also quite sure I checked to see that things were still working like they should when it was renamed to [hrc], so this surprises me quite a bit, to say the least; not sure what's happened here, nor why. Input sanitation really isn't that difficult, and particularly not so for an issue that's already been reported and seemingly fixed once.
If you don't mind sharing it: What was the exact input(s) you could use for [hrc=] while it was broken; just regular old "#FFF; <css code goes here>" or straight up ";<css code goes here>"?
Re: Alley: One thing MyBB thankfully has to do is replace most HTML/CSS-related non-alphanumeric characters with their respective HTML entities, which limits the potential for most XSS attacks due to bad (or nonexistent) template input sanitation for posts quite a bit. At least it removes the ability to directly inject inline scripts or otherwise directly modify the DOM on the element level, and XSSTC isn't an issue any more in modern browsers as far as I know. Still pretty bad indeed, though.
(05-13-2016, 01:10 PM)Error Wrote: If you don't mind sharing it: What was the exact input(s) you could use for [hrc=] while it was broken; just regular old "#FFF; <css code goes here>" or straight up ";<css code goes here>"?
It was the former, I just added some funny css that rendered the hr in display: fixed, changed the width and height, added negative margins, sprinkled a bit of !important and posted in the Player Requests.
The XSSTC might not have been as bad though because of the reasons you said. - i wasn't able to put in any script tags or execute JavaScript in any other way. I'd expect that someone capable could potentially put in some nasty stuff in there.
(05-13-2016, 01:55 PM)DragonLancer Wrote: You should put such things to PMs only.
I normally would, of course, but seeing as it's already been fixed in this case (and I've verified that quite a few times myself already) I see no harm in asking in public. I was just curious to see whether or not the last version of the input regex that I saw for [hr=<colour>] would have exhibited the same vulnerability.
(05-13-2016, 01:58 PM)Protégé Wrote:
(05-13-2016, 01:10 PM)Error Wrote: If you don't mind sharing it: What was the exact input(s) you could use for [hrc=] while it was broken; just regular old "#FFF; <css code goes here>" or straight up ";<css code goes here>"?
It was the former, I just added some funny css that rendered the hr in display: fixed, changed the width and height, added negative margins, sprinkled a bit of !important and posted in the Player Requests.
The XSSTC might not have been as bad though because of the reasons you said. - i wasn't able to put in any script tags or execute JavaScript in any other way. I'd expect that someone capable could potentially put in some nasty stuff in there.
Ah, alright; thanks for the reply! That wouldn't have been matched by the last version of the [hr=<colour>] regex that I saw, so it can't have been the one used in the live version of the template for [hrc]. Odd.
(05-13-2016, 02:01 PM)Error Wrote: Ah, alright; thanks for the reply! That wouldn't have been matched by the last version of the [hr=<colour>] regex that I saw, so it can't have been the one used in the live version of the template for [hrc]. Odd.
hrc was implemented through (.*?) which is NOT THE WAY OF DOING THINGS WHATSOEVER.
(05-13-2016, 03:12 PM)Protégé Wrote: hrc was implemented through (.*?) which is NOT THE WAY OF DOING THINGS WHATSOEVER.
No, absolutely not; that's the "nonexistent input sanitizing" case I mentioned earlier. \[hr=([a-z\-]+|#?[0-9a-fA-F]{6}|#?[0-9a-fA-F]{3})\] was the one used for [hr=<colour>] as far as I know - it was the last version I saw, and the user-facing behaviour of [hr=<colour>] seemed to be consistent with that regex - so I'm not sure what happened in the transition from [hr=<colour>] to [hrc]. Again: Odd, it almost looks like two different people implemented them independently.
EDIT: Not that how it happened matters much now that it's fixed, which is the most important thing; wasn't exactly planning on dragging that particular discussion out, it just strikes me as weird in hindsight that the [hr=<colour>] regex wasn't reused.
(05-13-2016, 05:43 PM)DragonLancer Wrote: Please make an old UBB-Hack providing guy happy and make this threat invisible.
Thanks.
There's no reason to. If we were discussing this subject while the exploit wasn't fixed then it might be a security problem but as it stands, it's fixed.
(05-13-2016, 05:33 PM)Error Wrote: No, absolutely not; that's the "nonexistent input sanitizing" case I mentioned earlier. \[hr=([a-z\-]+|#?[0-9a-fA-F]{6}|#?[0-9a-fA-F]{3})\] was the one used for [hr=<colour>] as far as I know - it was the last version I saw, and the user-facing behaviour of [hr=<colour>] seemed to be consistent with that regex - so I'm not sure what happened in the transition from [hr=<colour>] to [hrc]. Again: Odd, it almost looks like two different people implemented them independently.
Well, the one I asked Alley to replace the faulty one with isn't as long and complicated, maintains the functionality that it had previously (using the standard css colour names as well as the three character shorthands) and should also be relatively idiotproof. My guess is that the person who implemented this just looked at [indent] or something similar and didn't know how the regex works.