Jump to content

In-house CMS now GPL, looking for testers (bugs and security) and/or developers


Recommended Posts

Greetings PHP Freaks,

 

You may have noticed me stopping by here from time to time over the past few weeks. I've been reading and learning, posting and (I hope) helping. I make websites for a living, and in my spare time I have been creating a content management system to address some of the shortcomings found in other available systems. Until now I've been charging for it to earn back some of the cost of development time, but I've come to believe that it would be more beneficial to me (and certainly to anyone who wishes to use it) if I were to release it under the GPL. I potentially gain assistance in development and others get to use the software for free.

 

With that in mind, I have done just that. It is now available on github at:

https://github.com/Tarential/Saint-CMS

 

I also have a website for the software set up (saintcms.com) and a demo site running the latest beta which I'm hoping someone might help test for me:

http://demo.saintcms.com/login

Username: demo

Password: demo

 

Here is my confirmation file for testing:

http://demo.saintcms.com/phpfreaks.txt

 

I am looking for both security and bug testing if anyone would be so kind as to provide either. In addition, I would welcome anyone who is interested in helping further the development of this CMS. It is based around a generic block system that allows customization of repeating content types and has a modified MVC architecture similar to Magento. The administrative interface is inline for user friendly editing. Feel free to have a look around and contact me with any questions (either reply here, pm me or e-mail me via the contact form on my site).

 

Thank you all for your time,

Preston St. Pierre

  • Replies 50
  • Created
  • Last Reply

Top Posters In This Topic

Executed XSS in search form

unamed form::saint-search-phrase

 

 

solution

 

//outputting safely variable  using html 4 and UTF8 charset
htmlentities($variable,ENT_COMPAT,ENT_HTML401,'UTF-8');

Hello,

 

Thanks for the feedback. I have left the search output unfiltered on display because it only displays to the user themselves. Since it is not saved and never displays to anyone else, I am not sure how it can cause a vulnerability to XSS attacks. Would you please explain to me how this might cause a security problem? I'm very interested in ensuring no attacks can be made on the system.

 

Thanks,

Preston

Nevermind. I found the answer waiting for me in another thread! (http://forums.phpfreaks.com/index.php?topic=363293.0) Although I think if someone has been fooled into visiting a fake site there could be much bigger problems, like presenting a fake login, than presenting a fake search and inserting XSS code. Nevertheless, I will get on this problem right away.

 

If anyone finds another way in I would love to hear about it.

 

-Preston

It is GPL. I just made the change, so I may have missed a few places. If you're looking in the stable branch of the git repository you'll find the old license, but the new license is in the unstable branch. Where do you see it being not GPL?

Apache mod_negotiation filename bruteforcing

Vulnerability description

mod_negotiation is an Apache module responsible for selecting the document that best matches the clients capabilities, from one of several available documents. If the client provides an invalid Accept header, the server will respond with a 406 Not Acceptable error containing a pseudo directory listing. This behavior can help an attacker to learn more about his target, for example, generate a list of base names, generate a list of interesting extensions, look for backup files and so on.

Affected items

Web Server

The impact of this vulnerability

Possible information disclosure: directory listing, filename bruteforcing, backup files.

 

How to fix this vulnerability

Disable the MultiViews directive from Apache's configuration file and restart Apache.

You can disable MultiViews by creating a .htaccess file containing the following line:

 

Options -Multiviews

 

 

Vulnerability description

This file is listed in robots.txt but it's not linked anywhere in the site.

Affected items

/system

The impact of this vulnerability

Possible sensitive information disclosure.

 

How to fix this vulnerability

In robots.txt you should only include files or directories linked on the site.

 

Vulnerability description

The web server is configured to display the list of files contained in this directory. This is not recommended because the directory may contain files that are not normally exposed through links on the web site.

Affected items

/cache

/core

/core/images

/core/paypal

/core/scripts

/core/scripts/plupload

/core/scripts/tinymce

/core/scripts/tinymce/langs

/core/scripts/tinymce/plugins

/core/scripts/tinymce/plugins/advhr

/core/scripts/tinymce/plugins/advhr/css

/core/scripts/tinymce/plugins/advhr/js

/core/scripts/tinymce/plugins/advhr/langs

/core/scripts/tinymce/plugins/advimage

/core/scripts/tinymce/plugins/advimage/css

/core/scripts/tinymce/plugins/advimage/img

/core/scripts/tinymce/plugins/advimage/js

/core/scripts/tinymce/plugins/advimage/langs

/core/scripts/tinymce/plugins/advlink

/core/scripts/tinymce/plugins/advlink/css

/core/scripts/tinymce/plugins/advlink/js

/core/scripts/tinymce/plugins/advlink/langs

/core/scripts/tinymce/plugins/advlist

/core/scripts/tinymce/plugins/autolink

/core/scripts/tinymce/plugins/autoresize

/core/scripts/tinymce/plugins/autosave

/core/scripts/tinymce/plugins/autosave/langs

/core/scripts/tinymce/plugins/bbcode

/core/scripts/tinymce/plugins/contextmenu

/core/scripts/tinymce/plugins/directionality

/core/scripts/tinymce/plugins/emotions

/core/scripts/tinymce/plugins/emotions/img

/core/scripts/tinymce/plugins/emotions/js

/core/scripts/tinymce/plugins/emotions/langs

/core/scripts/tinymce/plugins/example

/core/scripts/tinymce/plugins/example/img

/core/scripts/tinymce/plugins/example/js

/core/scripts/tinymce/plugins/example/langs

/core/scripts/tinymce/plugins/example_dependency

/core/scripts/tinymce/plugins/fullpage

/core/scripts/tinymce/plugins/fullpage/css

/core/scripts/tinymce/plugins/fullpage/js

/core/scripts/tinymce/plugins/fullpage/langs

/core/scripts/tinymce/plugins/fullscreen

/core/scripts/tinymce/plugins/iespell

/core/scripts/tinymce/plugins/inlinepopups

/core/scripts/tinymce/plugins/inlinepopups/skins

/core/scripts/tinymce/plugins/inlinepopups/skins/clearlooks2

/core/scripts/tinymce/plugins/inlinepopups/skins/clearlooks2/img

/core/scripts/tinymce/plugins/insertdatetime

/core/scripts/tinymce/plugins/layer

/core/scripts/tinymce/plugins/legacyoutput

/core/scripts/tinymce/plugins/lists

/core/scripts/tinymce/plugins/media

/core/scripts/tinymce/plugins/media/css

/core/scripts/tinymce/plugins/media/js

/core/scripts/tinymce/plugins/media/langs

/core/scripts/tinymce/plugins/nonbreaking

/core/scripts/tinymce/plugins/noneditable

/core/scripts/tinymce/plugins/pagebreak

/core/scripts/tinymce/plugins/paste

/core/scripts/tinymce/plugins/paste/js

/core/scripts/tinymce/plugins/paste/langs

/core/scripts/tinymce/plugins/preview

/core/scripts/tinymce/plugins/preview/jscripts

/core/scripts/tinymce/plugins/print

/core/scripts/tinymce/plugins/save

/core/scripts/tinymce/plugins/searchreplace

/core/scripts/tinymce/plugins/searchreplace/css

/core/scripts/tinymce/plugins/searchreplace/js

/core/scripts/tinymce/plugins/searchreplace/langs

/core/scripts/tinymce/plugins/spellchecker

/core/scripts/tinymce/plugins/spellchecker/css

/core/scripts/tinymce/plugins/spellchecker/img

/core/scripts/tinymce/plugins/style

/core/scripts/tinymce/plugins/style/css

/core/scripts/tinymce/plugins/style/js

/core/scripts/tinymce/plugins/style/langs

/core/scripts/tinymce/plugins/tabfocus

/core/scripts/tinymce/plugins/table

/core/scripts/tinymce/plugins/table/css

/core/scripts/tinymce/plugins/table/js

/core/scripts/tinymce/plugins/table/langs

/core/scripts/tinymce/plugins/template

/core/scripts/tinymce/plugins/template/css

/core/scripts/tinymce/plugins/template/js

/core/scripts/tinymce/plugins/template/langs

/core/scripts/tinymce/plugins/visualchars

/core/scripts/tinymce/plugins/wordcount

/core/scripts/tinymce/themes

/core/scripts/tinymce/themes/advanced

/core/scripts/tinymce/themes/advanced/img

/core/scripts/tinymce/themes/advanced/js

/core/scripts/tinymce/themes/advanced/langs

/core/scripts/tinymce/themes/advanced/skins

/core/scripts/tinymce/themes/advanced/skins/default

/core/scripts/tinymce/themes/advanced/skins/default/img

/core/scripts/tinymce/themes/advanced/skins/highcontrast

/core/scripts/tinymce/themes/advanced/skins/o2k7

/core/scripts/tinymce/themes/advanced/skins/o2k7/img

/core/scripts/tinymce/themes/simple

/core/scripts/tinymce/themes/simple/img

/core/scripts/tinymce/themes/simple/langs

/core/scripts/tinymce/themes/simple/skins

/core/scripts/tinymce/themes/simple/skins/default

/core/scripts/tinymce/themes/simple/skins/o2k7

/core/scripts/tinymce/themes/simple/skins/o2k7/img

/core/scripts/tinymce/utils

/core/styles

/logs

/media

/uploads

The impact of this vulnerability

A user can view a list of all files from this directory possibly exposing sensitive information.

 

How to fix this vulnerability

create index file depends on server config on apache it is called index.htm ot index.html on IIS it is called default.asp or default.aspx or even default.html.on IIS directory listing is disabled by default. for apache edit the config file (httpd.conf) or create a .htaccess file in the spache config file you will find something like

 

<Directory directoryname/subdirectory> Indexes FollowSymLinks ... </Directory>

 

to disable the listing for that directory/subdirectory you will need to disable the Indexes option.

Thanks for the testing. I've disabled directory indexing and multiviews via htaccess. I also removed the ban on /system from robots.txt since that is only ever called from the admin account and accordingly does not appear to search engines anyway. Silly me for overlooking these things! I appreciate your help.

 

-Preston

either you missed directories or i am still picking up stuff.(false positive maybe?)

 

/cache

/core

/core/images

/core/scripts

/core/scripts/tinymce

/core/styles

/media/uploads

 

seems to be alot better than the last test though no picking up any multiview stuff and the google hacking temps for the most part have ceased.

 

 

 

It's not listing files in those directories, I added them to the ignore list. They appear to be empty but they aren't. Unless they appear differently to you? I see them as empty when I try to access them. The files all still need to be allowed access, so I haven't set up a deny like I did for other important directories.

  • 1 month later...

Insecure transition from HTTP to HTTPS in form post

Vulnerability description

This form is served from an insecure page (http) page. This page could be hijacked using a Man-in-the-middle attack and an attacker can replace the form target.

Affected items

/shop (17f8af95c7c0ccc19a865f9b8a65bfd1)

/shop (954cd437f1990a4dd7d3cc759638662a)

The impact of this vulnerability

Possible information disclosure.

How to fix this vulnerability

The form should be served from a secure (https) page.

 

 

Brute forcing Login Attack still Exists @ OP perhaps you might try the following.

 

http://lmgtfy.com/?q=brute+forcing+login+attack+php

You're right on one count, there appears to be a bug in my brute force prevention system. As far as non-ssl pages goes, I didn't purchase a certificate for saintcms.com and as such yes the entire site is vulnerable. However, whenever I log in to the administrative account I piggyback on my other SSL certificate. It's invalid for the domain, but I recognize it and it provides me with enough protection.

 

https://saintcms.com:444/

 

If you log in with https enabled the system should keep it enabled. I'm going to go fix the bug with brute force logins now. Thanks for the heads up!

I found not one but two bugs in the brute force protection system! Thank you for bringing this to my attention.

 

1) It was only logging attempts for accounts which existed. Fixed.

2) It was miscalculating the time and discarding the login attempts as too old to matter. Also fixed.

 

I haven't updated the demo page yet (it's actually two minor versions behind where it should be, something I intend to remedy as soon as I complete this release). I've added public commenting for blog posts (moderated) in 1.4.1, and 1.4.2 is bringing an enhanced file manager (drag n drop to upload, ctrl/shift drag to select/deselect files, bulk editing options) and a restyled administrative interface (more mobile friendly). The file manager is a real pleasure to work with now :)

 

Thanks again for following up and testing my system. I certainly intend to keep it around, so if anyone wishes to drop in from time to time and check on it as darkfreaks has that would be fantastic :)

To clarify my choice of GPL: I don't want my code to end up in a proprietary project (unless I'm being paid to work on the project). If there is another reason to dislike GPL besides the "viral" nature, I am open to listening and am not adverse to switching the license. As I wrote all the code the option is still open to me to license it as I will. Have a compelling reason I should switch? Tell me and I'll consider it.

GPL license has no copyright protection it pretty much states that anyone can redistribute or modify your code. i would suggest switching to the BSD license if you want copyright protection of the code.

 

 

 

 

 

 

I am not interested in copyright protection. Though I would be happy if anyone using my code in an open source project gave me credit, I don't intend to try to enforce it legally. My main concern is stopping people from using my code in a proprietary program. Still, as long as they don't distribute the program, I can't stop them from running a completely proprietary service on top of my code (at least that is my understanding of it, though I am not a lawyer).

 

I am surprised at such a negative reaction toward the GPL, but it was not my intention to start a dispute over licensing. I'm not trying to say it is "better" than any other license. I have chosen it, however, because it seems to provide the very qualities that I require for this particular piece of software. If, at any time, someone wishes to use my code in a non-GPL compatible (but OSI approved) project they can always contact me. Under legitimate circumstances I will grant these requests.

 

I appreciate all the help I've been given here so I don't want to appear ungrateful by arguing. I am simply trying to show that I did think about my decision before choosing a license (and I considered other options, such as the BSD licenses and the MIT license). It's likely that no-one saw this, and I've since let the site go down since then, but back in university I created a site called "Anti-FUD" on which I was going to publish controversial articles to drive traffic -- starting with a "GPL vs BSD" license. I did write that article, and it got slashdotted and sent to numerous other places. The reason it was so controversial is that both camps thought I ruled in the other side's favor, when all I actually did was outline the reasons that each was better for specific conditions.

 

I'm not claiming expertise in licensing or law, but suffice to say that I did my research before that article and I did further research before selecting a license now. I welcome any corrections if I've misunderstood one or more of the licenses.

 

rescanned found the same attacks both MIM attack and bruteforce guess login. however you might want to read this.

Did you try using the SSL enabled link I sent? Also, I have still not updated the code on the demo page, but I have fixed the brute force problem. I intend to finish this release before I update the demo, so it could be a few days. Thanks for being so prompt about the scanning, however :)

The GPL can present a real problem for those wishing to commercialize and profit from software. For example, the GPL adds to the difficulty a graduate student will have in directly forming a company to commercialize his research results, or the difficulty a student will have in joining a company on the assumption that a promising research project will be commercialized.

 

For those who must work with statically-linked implementations of multiple software standards, the GPL is often a poor license, because it precludes using proprietary implementations of the standards. The GPL thus minimizes the number of programs that can be built using a GPLed standard. The GPL was intended to not provide a mechanism to develop a standard on which one engineers proprietary products. (This does not apply to Linux applications because they do not statically link, rather they use a trap-based API.)

 

 

Also i have it scanning it hasnt found anything via HTTPS but  you can't deny switching from http to https does create a MIM attack which needs to be adressed instead of ignored.

The GPL can present a real problem for those wishing to commercialize and profit from software. For example, the GPL adds to the difficulty a graduate student will have in directly forming a company to commercialize his research results, or the difficulty a student will have in joining a company on the assumption that a promising research project will be commercialized.

This project will not be commercialized in that sense. It is already being commercialized in the sense that I use it for client websites. To that end, the GPL does not interfere with me in any way. You present two examples, but neither applies to me. Again, I do not defend the GPL as a whole. I defend it for this specific implementation of this specific type of software as it suits my purpose.

 

For those who must work with statically-linked implementations of multiple software standards, the GPL is often a poor license, because it precludes using proprietary implementations of the standards. The GPL thus minimizes the number of programs that can be built using a GPLed standard. The GPL was intended to not provide a mechanism to develop a standard on which one engineers proprietary products. (This does not apply to Linux applications because they do not statically link, rather they use a trap-based API.)

You are completely correct, but again this does not apply to my own circumstances.

 

Also i have it scanning it hasnt found anything via HTTPS but  you can't deny switching from http to https does create a MIM attack which needs to be adress instead of ignored.

I'm interested in this. I don't understand. In real world conditions, there would be no switching as I would force SSL in htaccess with mod_rewrite. Am I still vulnerable? If so, how? I do not intend to ignore any reasonable venue of attack.

Cross Site Scripting

Vulnerability description

This script is possibly vulnerable to Cross Site Scripting (XSS) attacks.

Cross site scripting (also referred to as XSS) is a vulnerability that allows an attacker to send malicious code (usually in the form of Javascript) to another user. Because a browser cannot know if the script should be trusted or not, it will execute the script in the user context allowing the attacker to access any cookies or session tokens retained by the browser.

Affected items

/blog

/blog/

/blog/category

/blog/category/

/blog/category/Saint

/blog/category/Saint/

The impact of this vulnerability

Malicious users may inject JavaScript, VBScript, ActiveX, HTML or Flash into a vulnerable application to fool a user in order to gather data from them. An attacker can steal the session cookie and take over the account, impersonating the user. It is also possible to modify the content of the page presented to the user.

How to fix this vulnerability

Your script should filter metacharacters from user input.

 

 

http://lmgtfy.com/?q=htmlpurifier+validation+php

I am sanitizing the input with the following code. Is it still vulnerable, or was there a false positive? If it is vulnerable, could you point out to me which characters I still must filter? Thanks.

$safe = mysql_real_escape_string($input);
$allowed_tags = array('p','b','i','u','em','strong');
foreach ($allowed_tags as $tag) {
$safe = str_ireplace('<'.$tag.'>','['.$tag.']',$safe);
$safe = str_ireplace('</'.$tag.'>','[/'.$tag.']',$safe);
}
$safe = htmlentities(strip_tags($safe), ENT_COMPAT | ENT_HTML401, 'UTF-8');
foreach ($allowed_tags as $tag) {
$safe = str_ireplace('['.$tag.']','<'.$tag.'>',$safe);
$safe = str_ireplace('[/'.$tag.']','</'.$tag.'>',$safe);
}
return $safe;

P.S. If you're wondering, the reason for the replacement loops is to allow simple bbcode style tags (and their html equivalents, which are first converted *to* bbcode, then back after the sanitization).

why the bloody hell are you using strip_tags and htmlentities? that will open you straight up for XSS injection.

 

 

if you want to escape xss  output it using.

 

$variable= htmlspecialchars($_POST['variable'],ENT_QUOTES,'utf-8');
//escapes most xss and is more tolerable than strip_tags or html_entities

 

 


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.