Dragonfly CMS v9 ⇒ Security v9 ⇒ Firesheep (Firefox extension) ⇒ Community Forums ⇒ CPG Dragonfly™ CMS
Forum IndexSecurity v9

Firesheep (Firefox extension) Reply to topic


Released yesterday. Link to developer's site, with link to source code.

Does Dragonfly's security/session features provide any protection from this? Aside from not likely being in the supplied list of "insecure website known to Firesheep" Wink Or should we be using https for admin at least?

Pro_News CM™ - Content Management for Dragonfly CMS™

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux / 1.3.39 - 2.4.9 / 5.5.42 - 5.6.16 / 5.4.37 - 5.5.11 / 9.4


We don't.
It's the responsibility of a website to setup an SSL certificate AND the responsibility of a visitor to secure his WiFi.

I've configured many insecure WiFi networks with a password so that the owner of the WiFi didn't have access any more, but then within a week the WiFi was fully open again because someone did reset the damn thing without securing it.
It's not the fault of Dragonfly CMS that many stupid people use the internet.

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


WEP/WPA/2 doesn't come into this, Firesheep apparently works on any shared network (wireless or wired). A shared WEP/WPA/2 network will be sharing the same WEP/WAP/2 key.

One of the commenters raises Drupal's alternate method: robertjtownsend said...
I think the Drupal "Secure Pages Hijack Prevention" module (http://drupal.org/project/securepages_prevent_hijack) uses an interesting approach, it uses a second login cookie only sent via HTTPS, and then logsout any user who attempts to visit a page without both cookies. Not foolproof, but may be acceptable on smaller "I swear the server can't handle the extra SSL load" websites.
Something to consider along with you newest login ideas, possibly?

Using https: for whole site seems to be the only solution - short of a VPN or Tor. My host claims SSL overhead/load is now low enough not to be detectable. But adding SSL on a shared host account raises cost considerably if using your own SSL certificate. Some hosts offer a modified URL like
https://{host_domain_name}/{your_domain_name}
for free but this all unravels pretty quickly with login taking you a CSS style-free login screen, and then to a 404 of
https://{host_domain_name}/admin.php
Any way to fix this via .htaccess yet still let users use http://{your_domain_name} as well?

[ Firefox extension HTTPS-Everywhere from EFF offers a nice way to redirect your browser to https for known sites - and you can add your own rule sets to add other sites. ]

Pro_News CM™ - Content Management for Dragonfly CMS™

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux / 1.3.39 - 2.4.9 / 5.5.42 - 5.6.16 / 5.4.37 - 5.5.11 / 9.4


Fortunately, some government authorities agree with you DJ - in at least one state in Australia, the police have a group that goes around detecting unsecured networks and they impose very heavy fines.

Aside from securing your site, it does raise the issue of vetting people that you give access to sensitive areas of your site.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):


It simply sniff packets (maybe install winpcap too) and by default will only support a limited number of websites detected by IP ranges. Then it just copy the GET request including cookie data.

You still need to be within a LAN and you MUST use a switch with a mirroring port or an old hub. If you are outside the LAN bla bla bla ...

HTTPS does work but the login form MUST be unique within the site .. eg. no logins from the user block or other places since the login page MUST be encrypted already.

.:: I met php the 03 December 2003 :: Unforgettable day! ::.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
CloudLinux / Apache 2.4 LSAPI / MySQLi 5.6 / PHP 5.6 / DCVS

All times are UTC


Jump to: