Remaining theoretical attacks

[rugk]

So here the remaining issues of the security audit:

• 4.2. urls2links XSS
• 4.5. Is SJCL used correctly?
• 4.6. Possible XSS in tpl/page.html

I mark this issue as "help wanted", so if anyone wants to look into this, feel free to do this. All of them are very theoretical and are therefore not serious.
If any issues may get obsolete (because the underlying system is changed, such as 4.5 when #28 is implemented, please also tick the issue).

[rugk]

As RainTPL has been removed is 4.6. still relevant?

[elrido]

All the returned variables currently get encoded/escaped, so I still consider this fixed.

Of course custom templates could have flaws, as the template creators needs to take care of the the escaping, too. We could move the escaping into the main PrivateBin class, then template creators don't have to mind and we reduce code duplication.

[rugk]

Okay, so for now I ticked 4.6.

[rugk]

Anything to do about "4.5."? Basically we can only write to the authors of SJCL.

[elrido]

We could do that, but really... Just compare our implementation (its these 10 lines) with the example given on their homepage and the details on the encrypt function in the API docs. There is really not much one could do wrong, is there?

[rugk]

I also think most issues may only be made with the parameters passed to SJCl and this would not be an "incorrect use of SJCL". So I tick this box too.

[rugk]

Okay, actually I found some things which are not clear to me there. I'll open a new issue for that.

[rugk]

So here it is: #74

Now we also really fixed 4.5.

[elrido]

Regarding 4.2: The only allowed protocols in the urls2link code are http, https, ftp and magnet. As these are hardcoded XSS that uses "javascript:" or hides the use of the same would not trigger URLs to be created.