XSS security - note validationIt took me MUCH time, but now we have a new "fature".
New note validation system is ready. Why was it introduced? What does it mean for players?
It's a system which performs html code validation when editing a note. It's done to make sure the note sticks to the standards and is safe for other players to view on their device.
The system intends to provide better security against cross-site-scripting (XSS) attacks, which in some circumstances can result in somebody getting your account credentials, session data or other interesting stuff.
We already had some protection against such attacks, but we know it became possible to bypass it (bad protection = no protection), so much had to be fixed manually by myself.
It is very important - this change affects only notes which are created or edited after the system change. None of the currently existing notes was changed, even if they were extremely incorrect.
One of the reasons why it took me months, was the intention of making the transition as easy as possible. So it's possible to see validated and corrected html source after requesting a preview, but before accepting it, as well as see changes done by validator (as a fine-grained diff). This way you can see what was wrong and you can correct it in the way you like, if you don't like validator's solution.
Correcting invalid tag structure is a side effect of ensuring safety. I've tested it on some notes and most of them passed it completely uhnarmed. Just a few are so bad that they can't be fixed in any automated way. It may be a good chance to fix them manually, with the help of the program.
If you leave "diff" unchecked and do preview, then the browser will send an ajax request to the server and in response you'll see a preview of the note after validation, which looks EXACTLY the same as when reading the note. It's better than old javascript-based preview emulation, because now preview doesn't look similar, it is EXACTLY the same as looking at a note after saving it.
If you check "diff" and request a preview, you'll see full char-by-char report of differences between original and validated note contents. It prints pieces removed by validator (things which are dangerous or not comply to html standard) on red background, while things added by validator are are marked with green. This way you can easily notice what actually happened.
If you try to edit your old note and preview shows there are lots of changes done by validator which you think are incorrect - don't save it and contact support. You'll most likely receive an answer that everything is ok and your old code was bad, but maybe it'll be one of situations where its the game code that causes problems
* * *
Q: I want to create a complicated note. What else can be important?
A: It's a more tricky part.
Some of common errors, which I've noticed when testing popular in-game notes:
- having <div> inside of <a> - it should be swapped
- having <div> inside of <span> or <p> - span is for text span, p is for paragraph, they can't be outside a div
- it was a surprise for me, "alt" for <img> tags is obligatory
- unclosed or duplicated tags are very common
Good thing is that most of the notes are almost ok and look the same after validation, even if amount of changes is HUGE. It won't work only for notes which are completely against html 4.01 transitional specification, which itself allows much more than should be allowed
but I kept it for backward-compatibility. For example "align" html attribute is accepted by spec, but you should use corresponding CSS style whenever possible. It won't be ok to disallow that to you when Cantr html source still has lots of that crap
Atypical design of Cantr notes requires a few other rules:
- only situation when <pre></pre> tags are allowed and secure: </pre> tag at the beginning of the note, <pre> tag at the end. It's rather tricky, but many people know it already. Use it only if you want to get rid of default newline characters supplied by Cantr. If you do it the other way, then you do it at own risk. If you need <pre> anywhere else, then I suggest to use <div style="white-space:pre-wrap"></div> instead. It does more or less the same (except setting monospace font) and allows other html tags inside.
- if you need your own cascading style sheet (CSS), then you should specify it at the beginning of the note. It should be defined by: '<style type="text/css">' and ended with '</style>'. IT MUST EXACTLY MATCH THIS PATTERN. Otherwise whole of your CSS will be completely removed.
- CSS definitions are validated separately. CSS classes and IDs can contain only alphanumeric characters, "_" and "-". They should start with a letter.
- validator is quite liberal when it goes to CSS properties. For example it allows "display:none" or "position:absolute". But you shouldn't assume that everything that passes validation is automagically ok. Notes should still be treated as something (usually) made of paper of other "static" material. For example ":hover" CSS selector should be generally avoided, unless it fits well somewhere. If you have any doubts - ask GAB