This is a MAJOR problem affecting over 95% of our community. This is not a simple spammer, this is a program designed to bypass our signup process and it should be top priority for everyone in the oxwall team to keep our websites secure by finding the flaw in our script that allows this program to achieve this!
If you agree simply reply with +1 to keep this thread alive or feel free to chime in and let oxwall know what fixing this issue means to you!
Leader
Could this have something to do with it?
OxWall contains a flaw that allows a remote cross-site scripting (XSS) attack. This flaw exists because the application does not validate the 'month' parameter upon submission to the blogs/user/username script. This may allow a user to create a specially crafted request that would execute arbitrary script code in a user's browser within the trust relationship between their browser and the server.
796322012-02-20OxWall index.php plugin Parameter XSSOxWall contains a flaw that allows a remote cross-site scripting (XSS) attack. This flaw exists because the application does not validate the 'plugin' parameter upon submission to the 'index.php' script. This may allow a user to create a specially crafted URL that would execute arbitrary script code in a user's browser within the trust relationship between their browser and the server.
796382012-02-20OxWall /join Multiple Parameter XSSOxWall contains a flaw that allows a remote cross-site scripting (XSS) attack. This flaw exists because the application does not validate the 'captchaField', 'email', 'form_name', 'password', 'realname', 'repeatPassword and 'username' parameters upon submission to the '/join' script. This may allow a user to create a specially crafted URL that would execute arbitrary script code in a user's browser within the trust relationship between their browser and the server.
796392012-02-20OxWall /contact Multiple Parameter XSSOxWall contains a flaw that allows a remote cross-site scripting (XSS) attack. This flaw exists because the application does not validate the 'captcha', 'email', 'form_name', 'from' and 'subject' parameters upon submission to the '/contact' script. This may allow a user to create a specially crafted URL that would execute arbitrary script code in a user's browser within the trust relationship between their browser and the server.
796402012-02-20OxWall /blogs/browse-by-tag tag Parameter XSSOxWall contains a flaw that allows a remote cross-site scripting (XSS) attack. This flaw exists because the application does not validate the 'tag' parameter upon submission to the '/blogs/browse-by-tag' script. This may allow a user to create a specially crafted URL that would execute arbitrary script code in a user's browser within the trust relationship between their browser and the server.
796412012-02-20OxWall /viewlist URI XSSOxWall contains a flaw that allows a remote cross-site scripting (XSS) attack. This flaw exists because the application does not validate input passed via the URL upon submission to the '/viewlist' script. This may allow a user to create a specially crafted URL that would execute arbitrary script code in a user's browser within the trust relationship between their browser and the server.
LeaderIf i recall some of this can be avoided by not allowing users to customize the dashboard, profile page, and groups page. If i remember correctly just taking that check mark off of those items on the bottom of those settings takes care of some of this. The hole had to do with allowing users access to posting js commands. Again i may be wrong on this but i think i read that someplace.
Also most cross script vunerability can be handled quite simply by using htmlspecialchars or htmlentities, trim, and strip_tags on the user side and on the server side escaping right before you post to the db and when you display user side use stripslashes on that data you escaped when you pull it from the db.
Also i forgot to mention that if the data is an integer value there is no vulnerability so if for instance they use timestamp for the month as in the first example, there is no need to validate.
Update, although i am new to PDO i do have enough experience to be able to track down items or at least see if there has been an effort to effectively sanitize. I have not found any evidence that would cause me to believe that this has not been done, they are using functions to sanitize before heading into the db and they do seem to sanitize before displaying.
That does not mean there might not be something i am not seeing, but just going thru the once over it does appear they are doing things correctly. Is there more that can be done, im sure there is because it is the same with every software, rules and coding functions are changing on a daily basis at times and it is hard to keep up with it at times.
I would recommend that the DEV people of Oxwall take a look at these items and confirm they have all been properly sanitized, i feel they are but i am not Oxwall DEV and you know much more than i do about your flow of data.
Anti spam solution from before that works.
http://www.oxwall.org/forum/topic/10751
Spam isn't a problem if you make approval manditory. Because then you can just delete the spam accounts without them mucking up your website with BS blogs or forum posts.
Spam accounts are easy to spot because the names are extremely bogus and requires profile information will also show you that they're not real. Because they put stuff like "fefsdklfsdf" in the blanks.
There should be a better solution. The bottom line is that a flaw can be found in our script somewhere that makes us vulnerable. This flaw has to be found and fixed! Saying the only way to be spam free is by getting rid of features or countries is ridiculous.
Regardless, don't expect everything to be perfect when you are getting something for free.
I'd much rather worry about the new version update. Than a security flaw that can be solved by plugins or preventitive measures. Like Manditory Approvals.
because you are paying literally paying their teams salaries.
Than a security flaw that can be solved by plugins or preventitive measures. Like Manditory Approvals.
There are plenty of pieces of software out there that have been built from oxwall software that do not get attacked like this! (skafla) You also have to keep in mind that after buying a few hundred dollars worth of plugins and selling credits or subscriptions the last thing you want is someone to bypass your sign up process. So my point is here on oxwall you will find a community of people payinf for brand removal and buying plugins left and right. we spend money on our sites and we need them to be secure. Am I wrong to suggest that oxwall should acknowledge that!
TeamThanks to OxwallAccessories to bring this up.
We fix it immediately, if any potential security hack is report. As security is that most important thing in open source, which can't be postponed.
Let me comment each of reported cases:
1) OxWall blogs/user/username month Parameter XSS
Has been fixed since version 1.4.1 (confirmed in blog post )
2) OxWall index.php plugin Parameter XSS
Has been fixed since version 1.2 (confirmed on IIS), check it on your site by typing http://www.yoursite.com/ow_updates/?plugin=%27%22%28%29%26%251%3CScRiPt%20%3Eprompt%28982087%29%3C%2fScRiPt%3E
3) OxWall /join Multiple Parameter XSS
4) OxWall /contact Multiple Parameter XSS
5) OxWall /blogs/browse-by-tag tag Parameter XSS
Has been fixed since version 1.2 (confirmed on ISS , SecLists)
As for the spam problem, which affected a huge amount of sites powered by Oxwall... as I mentioned here , since the version 1.5.3 the special script has been implemented into the join process. It prevents your site join form from automatic bot submissions (like spam machine with white user avatar). Also, there are a lot of antispam plugins are designed to prevent human spam (like block by IP, email, etc.). Upgrading to version 1.5.3 + using up to date spam tool should prevent your site from the most spam activity, especially when your site starts to grow.
Thank you :)
