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 25 '17
After our internal discussion, my team stated that having a regex that adds http and https is best for the hyperlink xss. For any other XSS that is due to unsanitized user input, htmlspecialchars() and/or htmlentities() should do the work. 
AppXprt
AppXprt Jun 25 '17
Yea except htmlspecialchars and htmlentities make some ugly strings in the end, I experimented with that yesterday and I would rather remove the attack string all together as it would likely be gibberish with the XSS removed.

I have found a pretty awesome and straight forward solution to this, but I would like to say that I am just an OxWall user and not one of their dev's. I just have php experience and am getting into the oxwall system for customization and I am providing this for those who are interested or not willing to wait for the REAL dev's to fix these issues. With that being said, it is fairly easy to mitigate this in a much more comprehensive manner.

I started with checking out voku/Anti-XSS

but I think we should probably incorporate this eventually in place of custom html escaping: http://htmlpurifier.org/ (Not sure of licensing)


I'm a big fan of incorporating open source everywhere possible and the main reason I went with Anti-XSS is that it's MIT licensed

So, to make this at easy and as painless as possible, we're going to use composer to install what we need and make it super easy on us.


Go to your php.ini or dump phpinfo() and see what directory is being used for your include directory:

include_path = ".:/usr/share/php


You'll want to install the composer vendor directory into that include directory, but it's best to start in your home directory to prevent permission issues, but just Follow This to Install Composer


Use composer to grab everything for anti-xss (This can also be used to grab all sorta of PHP libs like Facebook Graph API):


php composer.phar require voku/anti-xss

Composer creates a vendor directory in your ~/composer/(vendor)


Move that to your php include directory: cp -R vendor/ /usr/share/php
or whatever your php include directory might be or you want to use... (there are other ways to include this as well)

Now for the edits...Edit with your favorite editor:

ow_plugins/forum/bol/forum_service.php

At the very top you're going to require the composer autoload script:


<?php

require 'vendor/autoload.php';

Now there are just a few edits to kill this in the forums:


We need to edit addPost(), editPost()editTopic(), addTopic()... And probably more, but we'll start with these.

public function addPost( FORUM_BOL_Topic $topicDto, array $data )    {        

$antixss = new voku\helper\AntiXSS;

$postDto->text = $antixss->xss_clean(UTIL_HtmlTag::stripJs(UTIL_HtmlTag::stripTags($data['text'], array('form', 'input', 'button'), null, true)));


public function editPost( $userId, array $data, FORUM_BOL_Post $postDto )    {      

$antixss = new voku\helper\AntiXSS;

$postDto->text = $antixss->xss_clean(UTIL_HtmlTag::stripJs(UTIL_HtmlTag::stripTags($data['text'], array('form', 'input', 'button'), null, true)));


 public function editTopic($userId, array $data, FORUM_BOL_Topic $topicDto, FORUM_BOL_Post $postDto, FORUM_BOL_Section $forumSection, FORUM_BOL_Group $forumGroup)    {


$antixss = new voku\helper\AntiXSS; 

$postDto->text = $antixss->xss_clean(UTIL_HtmlTag::stripJs(UTIL_HtmlTag::stripTags(trim($data['text']), array('form', 'input', 'button'), null, true)))


public function addTopic( $forumGroup, $isHidden, $userId, array $data, $forumSection = null )    {

.........

$antixss = new voku\helper\AntiXSS; 

$postDto->text =$antixss->xss_clean(UTIL_HtmlTag::stripJs(UTIL_HtmlTag::stripTags($data['text'], array('form', 'input', 'button'), null, true)))


Strips that shit out completely including "javascript:", but probably protects against a hell of a lot more (check out Anti-XSS)

Now just remove the previous mitigation I mentioned for removing href entirely and your linking works again, but without XSS.

The Forum post is edited by AppXprt Jun 25 '17
Securify Red Team
Securify Red Team Jun 25 '17
This is actually not a bad idea. Were you able to put that in your local oxwall installation and see how it performs? If not we can try it on ours and see if there is any bypass. 
AppXprt
AppXprt Jun 25 '17
Yes I was able to include in my dev setup and it works pretty nicely. Feel free to try it out over at https://dev.vixiv.net
The Forum post is edited by AppXprt Jun 25 '17
Securify Red Team
Securify Red Team Jun 25 '17
Cool. I sent it to our lab team. We will be checking that out soon. Thanks Zach!
AppXprt
AppXprt Jun 25 '17
Hmm we should probably be using this vendor include path:
ow_libraries/vendor/


with OW_DIR_LIB 

Going to test and update this post


Update:
So you can include all of this in ow_libraries/vendor directory to stay more uniform with OxWall Development, although you are not able to debug as easily through the CLI since the OW Directory paths in config.php aren't being utilized when running through the cli, but this is probably what oxwall devs would prefer.


I am not going to go about how to do this part though, because it is more complex by dealing with composer, its autoload, and permissions so this will be reserved for incorporating this or another fix into the repositories by the devs when they make an official decision as they will likely want to include it under ow_utilities. The problem is solved in a fairly easy manner without the need for all of this, but it is very possible to include Anti-XSS in with the ow_libraries to be more uniform with their programming style and conventions:


require_once OW_DIR_LIB . '/vendor/autoload.php';

The Forum post is edited by AppXprt Jun 25 '17
Securify Red Team
Securify Red Team Jun 25 '17
Zach, my team wanted to confirm if you are fine with us using your website to test the Anti-XSS script because you already have it setup there. When we test, we will have two accounts created one as "Attacker" and the other as "Victim". The payloads will be harmless and will just have document.domain as the alert. If you are ok with it or have any questions please let us know. 


Thanks again for helping so much on this! Securify Lab

AppXprt
AppXprt Jun 25 '17
Absolutely, please use https://dev.vixiv.net
Incorporated properly in the ow_libraries path and ready for your tests
The Forum post is edited by AppXprt Jun 25 '17
Securify Red Team
Securify Red Team Jun 25 '17
@Zach please check the message I sent you.
AppXprt
AppXprt Jun 25 '17
Sent you a reply...
This is mitigated the same way for Blogs as well: https://dev.vixiv.net/blogs (and production)
If you want to test that on dev as well...
AppXprt
AppXprt Jun 25 '17
Events are vulnerable as well:
https://dev.vixiv.net/event/1
AppXprt
AppXprt Jun 25 '17
As well as Groups:

https://dev.vixiv.net/groups/1

Securify Red Team
Securify Red Team Jun 25 '17
Yup seems like this is a global issue on the hyperlink function. If we knew exactly where the code was it would be great. When the Anti-XSS was there we noticed that it was good at blocking javascript attack through hyperlink but what came to notice was that the hyperlink url is not sanitized at all. If you put "><marquee>hi</marquee> then the code gets executed because "> breaks the href. So we will need to sanitize that as well along with preventing xss at all cost. 
Securify Red Team
Securify Red Team Jun 25 '17
Is @Norias a dev for the Oxwall community or are they just a user?
Norias
Norias Jun 25 '17
Just a user reading you guys, hoping you find a solution because my coding skills just let me understand what you say but not much more..
AppXprt
AppXprt Jun 26 '17
Come on, where are the site admins and devs?
Senior Developer Leader
Senior Developer Jun 26 '17

This is the place you are looking for:


ow_system_plugins\base\bol\text_format_service.php


You can sanitize the html inside the method "processWsForOutput", add your code just before the "return $text;"


If you do it in there, it applies to all the default wysiwyg textareas, that way the changes applies for all the plugins and the core too.


If you want, you can contribute in the github project directly, the oxwall team rarely read the topics in this forum, all the changes and help is better to do it directly on github.


http://www.github.com/oxwall/oxwall


I'm not an oxwall team member either, just another volunteer.


Senior Developer

Securify Red Team
Securify Red Team Jun 26 '17
Cool thanks! 
AppXprt
AppXprt Jun 26 '17
I have so many questions about the system and plugins SDeveloper, do you mind if I PM you sometime?
Senior Developer Leader
Senior Developer Jun 26 '17
Hi ViXiV Technologies!


Sure, PM me anytime. If your question can help others we can discuss it in the forum too, you can ask anything you want.


Senior Developer

Pages: « 1 2 3 »