Dragonfly CMS v9 ⇒ Security v9 :: Archives ⇒ Security Issues require clarification :: Archived ⇒ Community Forums ⇒ CPG Dragonfly™ CMS
Forum IndexSecurity v9

Archived ⇒ Security Issues require clarification


Dear Developers,

I have few questions in my mind. Could you clarify me? I may sound stupid. But still...

1. In what way DF secures from XSS attacks?
2. Do we have significant protection from Java script based attacks?
3. Has converting of special characters to HTML coding is being taken care?
4. Can I turnoff the HTTP TRACE in appache? Will it cause any problem in the functionality of the site?
5. Have we taken care from SQL injection?

6. Have taken care to protect from buffer overflow attacks?

May be DJ Maze could clarify me these questions.

Could you please clarify me the above questions?

Sattvic

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
WindowsXP\\APACHE\\MYSQL\\DragonflPHP5.2.1


1. depends
2. depends
3. no, not needed for UTF-8
4. yes and the second no
5. yes
6. depends

#1 and #2 are possible for the visitor itself. Anything outside your website (proxies, firebug, etc. etc.) can modify content any way they want, so yes it is possible in some extend.
However, when you post (submit) something to the website, as an user, it is cleaned up before it goes into the database.
But be aware that we never know if this is also the case for 3rd party extensions.

#6 totally depends on the software that any website needs, we are not responsible for bugs of Apache, PHP or your DBMS.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Fedora 25 / Apache 2.4.27 / MariaDB 10.1.26 / PHP 7.1.10 / Mercurial


sattvic2780 wrote
Dear Developers,

I have few questions in my mind. Could you clarify me? I may sound stupid. But still...

1. In what way DF secures from XSS attacks?
2. Do we have significant protection from Java script based attacks?
3. Has converting of special characters to HTML coding is being taken care?
4. Can I turnoff the HTTP TRACE in appache? Will it cause any problem in the functionality of the site?
5. Have we taken care from SQL injection?

6. Have taken care to protect from buffer overflow attacks?

May be DJ Maze could clarify me these questions.

Could you please clarify me the above questions?

Sattvic


Interesting if meaningless questions. I think DJMaze answered as meaningfully.

It's not enough to say what does 'DF' do, but it's more important in 'how you implement DF' that is far more important. Direct questions into how modules/themes will interact with the DF core would be more meaningful.. If it wasn't XMas eve I'd even write a story about it but I've other things to do, and perhaps we'll give you some time to find more meaningful questions that are not so esoteric.

You can have the most insecure code in the world never be subject to many of these attacks if you understand this and mitigate your consequences accordingly.

J.
j e r u v y a t y a h o o d o t c o m

Need help? Look here: www.dragonflycms.org/W...d=112.html
Need to chat? Look for me on irc.freenode.net

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Ubuntu7.10/Debian3.1 - 2.2.3/1.3.37 - 5.0.38/4.0.27 - 5.2.1/4.4.7 - CVS/9.1.2}


Hi DJ,

Thank you a lot for sparing your time and for your answers.

Sorry that I have asked you meaningless questions. I require to give answers to someone for the stated questions. Again I am not an expert.

Once again thanks a lot.

Sattvic.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
WindowsXP\\APACHE\\MYSQL\\DragonflPHP5.2.1


Don't be sorry. Questions are good. Meaningful questions will acquire meaningful answers.

Your questions look at this as black and white. Either it's 'immune' or it's 'affected'. Security is typically never so black and white. Generally a lot of gray. Additionally the questions show a lack of understanding the features of dragonfly.

XSS scripting attacks are mitigated and reduced in DF. PHP does nothing to stop XSS (in some cases XSS is valuable or necessary, think paypal or googlesense), and improper XSS is left to the developer to implement. Eliminating them 100% is a difficult goal since the methods of using XSS are still growing every day.

How does an application that uses javascript, or worse uses 3rd party javascript control the applications parameters? This requires indepth knowledge of all aspects of the tool and how it will be used. Java was not designed to be so tightly controlled, and a malicious author can typically break if the code isn't very well written. So javascript like PHP can be the problem, but isn't necessarily so.

Has dragonfly planned for the obvious problems? Sure. Have we fixed all the problems that could possibly occur? Not likely, it's just not possible.

Give you an example, when I test dragonfly for BASIC XSS attacks, it will take about 80 hours to run through all the code to check that. If tomorrow a new method is discovered and I decide to check against that, I'm back to square one. How many days do I have 80 hours to run a test? None Smile

Every dynamic site is subject to XSS attacks, many have 'reduced' the risk with good coding techniques. Will that change tomorrow, I sure hope so. I want to think that the code is improving (PHP in this example) hence why new versions of PHP come out.

Converting special chars to HTML is an area dragonfly spent a great deal of time working with. But this is no protection against evil DNS responses, or evil web hosts. If your DNS server gives you improper results regarding a URL, then all bets are off. It's important that the application (dragonfly in this case) doesn't mangle them, but once it hands off the data its out if it's control, same as when the queries come back. It's unlikely that dragonfly could be used as a source of such an attack, but it could be manipulated by one easy enough. Since we implemented UTF-8 any mangling of results would be a bug in the standard or the implementation.

HTTP trace is a troubleshooting/debugging method, and should be disabled on production web sites. Since this is under the direct control of the web hosting provider it's outside the scope of dragonfly to control. None of dragonfly's code uses TRACE methods (and it would be poor coding if it did since as I stated many cases it's the domain of the web host, not the application.

SQL injection is one area dragonfly has effectively immunized against. There are some area's it could be done, but not successfully. Could dragonfly be subject to a SQL injection in the future? It's possible. Some attacks will outgrow the immunization. If the attacker circumvents dragonfly then other options may avail themselves to a successful attack.


What's more important than the question you ask is one you should have asked, or even reviewed on this site which is:

"How responsive to security incidents are the DF developers?"

Very. I could direct you to 'securityfocus.com' to look for disclosed incidents in dragonfly. You can see that in each case (and many others posted in these very forums) any time a bug was found in dragonfly and it was properly reported, the issue was fixed in short order.

The code has also been checked by many experts in penetration testing, and results have been minor.

So to me the only question that leads to a meaningful answer would be 'how quickly are vulnerabilities fixed?', and anything under 30 days is decent response. I think you'd find that dragonfly is much more responsive.

Just look how long it takes to release a RC or a package Wink The developers do not release updates just because its that time of the month.

J.
j e r u v y a t y a h o o d o t c o m

Need help? Look here: www.dragonflycms.org/W...d=112.html
Need to chat? Look for me on irc.freenode.net

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Ubuntu7.10/Debian3.1 - 2.2.3/1.3.37 - 5.0.38/4.0.27 - 5.2.1/4.4.7 - CVS/9.1.2}

All times are UTC