evil robots, scripts.
wow, unfiltered xss put site in maint mode, changed password, locked out of site.
48% of security advisories for drupal are XSS (core & contrib)
[note to self for webform/campaign monitor integration: suggestion from prev presenter to create submodule based on webformphp]
71% of sites tested by whitehat have xss vulnerabilities.
a month of bugs…only 1 was really severe, about half were xss, more moderate.
changing the default input format. (done. actually, I think my default is a plain text version.) better formats module, which I’m using, and like a lot. html purifier module for use w/wysiwyg.
unsafe: script, object, embed, style, iframe, img (maybe: can be used as a vector for other attacks; don’t use for anon users) – but other tags can run into problems, whitelist is better.
dangerous permissions: administer… filters, users, permissions, content types, site configuration, views. “least privilege” side benefit: makes the interface much simpler for those users.
devel module – anon permission to execute php. (an actual live .edu site. jeez.) “I swear it was that way when I found it”
same criteria you’d use to evaluate the quality of a module can be used to evaluate security of the module. indirect & subjective, but a good starting place.
University of Pennsylvania “drupal approved modules” – staff who have audited the code, no guarantees, but has been reviewed.
coder module will give information about use of coding standards, another way of judging attention to detail. someone’s working on an add-on “secure code review”
xsrf – request forgery – anytime where visiting a page does something…potential flaw – if you see big crazy number (token) at the end, that’s good. (same sort of thing happens in ob.)
test for access bypass, with a variety of roles and permissions: what features still work if logged out? a flaw in code may allow inappropriate access: node access control + filefield – private node files could still be accessed as if public.
securepages – oh, our apache config is already set up for that (redirect to ssl version) – but has some maintenance issues
password_policy or password_strength
role_delegation – moderator can give moderator access to others, w/out full admin users permission
video_filter – safe way to post youtube, etc. w/out allowing script. difference from mfield?
adminrole – which I’m using and really like. (I turn the admin user off most of the time.)
always test updates before going live. drush pm-update. all updates w/single command – time-saver! read the advisories: not all issues apply to everybody.
crackingdrupal.com, owasp.org
discussion of password security, expiration, enforcing strong passwords. greggles talked about false sense of security about strong passwords, better to work on detecting brute force attacks. (there’s a module for the latter, login_security)