We build. You grow.

Get best community software here

Start a social network, a fan-site, an education project with oxwall - free opensource community software

Stored XSS on 1.8.4 Blog Section | Forum

Securify Red Team
Securify Red Team Jun 22 '17
This xss is located in creating blog and other sections where hyperlink is allowed. PoC click this for example. CVE for this is: CVE-2017-9824. CVE site should have limited info added on this soon. (~1 week)


The Forum post is edited by Securify Red Team Jun 24 '17
Securify Red Team
Securify Red Team Jun 22 '17
Make sure that the link being used is secured and the user input is properly checked/sanitized. 
Securify Red Team
Securify Red Team Jun 22 '17
This vulnerability works on multiple part of the application. Forum, Blog and message functionality to name the few. 
AppXprt
AppXprt Jun 23 '17
Do you know where the php handling this is located? New to this platform, but I can take a stab at sanitizing...
AppXprt
AppXprt Jun 23 '17
Uhhhh Yea....

Click 

Lets get on this like now...

The Forum post is edited by AppXprt Jun 23 '17
AppXprt
AppXprt Jun 23 '17
Okay, I was able to find this in the code and there are a few ways to mitigate this, although one is Superior and obviously the route to go... 

To mitigate this and remove easy XSS, edit the following file:

ow_utilities/html_tag.php


Search for stripJs Function, which looks like this:

   stripJs  {        $tags = array('script');    /**     * Removes <script> tags and JS event handlers.     *     * @param string $text
     * @return string     */    public static function stripJs( $text )    {        $attrs = array(            'onchange',            'onclick',            'ondblclick',            'onerror',            'onfocus',            'onkeydown',            'onkeypress',            'onkeyup',            'onload',            'onmousedown',            'onmousemove',            'onmouseout',            'onmouseover',            'onmouseup',            'onreset',            'onselect',            'onsubmit',            'onunload');        $jevix = self::getJevix($tags, $attrs, true, false);        return $jevix->parse($text);    }


Add href attribute to be stripped before onunload:

            'href',


 so you have:

$attrs = array(            'onchange',            'onclick',            'ondblclick',            'onerror',            'onfocus',            'onkeydown',            'onkeypress',            'onkeyup',            'onload',            'onmousedown',            'onmousemove',            'onmouseout',            'onmouseover',            'onmouseup',            'onreset',            'onselect',            'onsubmit',            'href',            'onunload');

 This is the simplest and quickest way to mitigate this at the moment.

The Forum post is edited by AppXprt Jun 23 '17
Norias
Norias Jun 24 '17
Thank a lot for sharing this information with us !


@Zach Jones : your solution is good for mitigation of this xss, but now it's impossible to put links in posts. Is there a way to block only the alert() function ?


AppXprt
AppXprt Jun 24 '17
Yes there are, I was working on that last night around 1 but the internet got disconnected, I'll have something for that today. The first mitigation is just to prevent attacks, but it does make linking anything impossible. Stripping out Alert isn't really effective, as the XSS is still there, you just can't use alert to identify the XSS super quickly and have it return values, but a true XSS wouldn't alert the user anyway. So a hacker could install OxWall and develop their XSS to the point that they want and remove any debugging info like alerts and such and have a completely effective XSS attack, because we decided to just strip the alert to throw off a few skids... 

Truthfully, I think we should be using the php functions htmlentities() or htmlspecialchars() to effectively and completely mitigate XSS, while identifying some of the most common attacks like alert and turning it around on them by alerting that the incident is being recorded and their IP address has been logged. We need a way for reporting XSS to the server side, so I'll look into that too.

https://paragonie.com/...ything-you-need-know

There are also evasions for our mitigation's so what ever they or we decide, we should be mindful of these: 
https://www.owasp.org/..._Evasion_Cheat_Sheet

The Forum post is edited by AppXprt Jun 24 '17
AppXprt
AppXprt Jun 24 '17
Let's work on this together, we should identify the tags that are most susceptible to XSS and be filtering this if we truly want HTML/javascript to be allowed in them. Allowing JS in HREF or ONANYTHING is basically just asking for trouble.
Securify Red Team
Securify Red Team Jun 24 '17
I recommend that you force user to have or on the link. For my payload I said i simply put javascript:alert(document.domain). If you force or and make sure user cannot add enclosed quotations like " then you should be fine. Norias.
Securify Red Team
Securify Red Team Jun 24 '17
Our team can help guide you if necessary. We have one more basic vulnerability we found that we will be uploading here soon. Recently, we have been testing security of open source sites so oxwall is one of them. 
Securify Red Team
Securify Red Team Jun 24 '17

Quote from Zach Jones Let's work on this together, we should identify the tags that are most susceptible to XSS and be filtering this if we truly want HTML/javascript to be allowed in them. Allowing JS in HREF or ONANYTHING is basically just asking for trouble.
You can prevent that like we said by forcing http or https. The feature is to add a link, so i do not quite get why you will remove that. 
Securify Red Team
Securify Red Team Jun 24 '17
like this won't work

but this will

because one has href="http://javascript:alert(document.domain)" and the other has href="javascript:alert(document.domain)"

Securify Red Team
Securify Red Team Jun 24 '17
Hopefully this clears things up. 
AppXprt
AppXprt Jun 24 '17
I feel like that is a bit of a cheap fix, but it would seem to be effective.


Still, I would like to see something more comprehensive like: 

https://github.com/voku/anti-xss/

https://github.com/voku/anti-xss/blob/master/src/voku/helper/AntiXSS.php


To help prevent evasions, and href might not be the only attack vector.

The Forum post is edited by AppXprt Jun 24 '17
Securify Red Team
Securify Red Team Jun 24 '17
You are correct. Once we have more xss we will update it here. but my question is the vulnerability as you saw is when adding a hyperlink. if you were to add blockage to "href" then how will hyperlink work?
AppXprt
AppXprt Jun 24 '17
Yes I understand this issue, it is to eliminate the issue for the moment only.

I am looking into how phpBB3 handles these types of issues.

The Forum post is edited by AppXprt Jun 24 '17
Securify Red Team
Securify Red Team Jun 24 '17
Cool, we are testing phpBB's security as well. If we find sth interesting it will be published :) 
Norias
Norias Jun 24 '17
ok, understand that alert() is not the problem. This was a stupid question.

I have a other one : can't we just strip "javascript:" from any user input ? 


We can hide the link containing "javascript" with css :


div.post_content span.ow_ws_link a[href*="javascript"] {visibility:hidden;}


But this is really not a good solution, and there are other forms of xss... 



Securify Red Team
Securify Red Team Jun 25 '17

Quote from Norias ok, understand that alert() is not the problem. This was a stupid question.

I have a other one : can't we just strip "javascript:" from any user input ? 


We can hide the link containing "javascript" with css :


div.post_content span.ow_ws_link a[href*="javascript"] {visibility:hidden;}


But this is really not a good solution, and there are other forms of xss... 



Correct. We could try to strip javascript from the href which could help. As I said earlier regarding XSS, our team is analyzing the project in our own lab so any other form of XSS that we find will be added here. Also you are right that alert() is not the only thing that goes with XSS. Based on my talk with my colleagues at the team, for a temporary fix they are saying that automatically adding a someway like this <a href="http:"+[user_input]> could prevent XSS here.


In overall however, to prevent XSS, one thing will be to sanitize every user input. This is done in most part of the application. So like using htmlspecialchars() or htmlentities() can prevent it because then <script> will be converted to prevent the XSS from occurring.

I have a discussion with my team tomorrow. I will check with them and as soon as we have more info, I will let you guys know. One of my team member is actually going through the source code and checking instance for the fix. If he fixes the XSS, I will post it here. 


Thank you, 

Securify Lab  

Pages: 1 2 3 »