doteduguru

Welp, another week, another conference.  Time to say goodbye to most of you for another few months.  Next on my book is the Open Minds dotCMS user conference in February, but most of you won’t be at that.  More pictures are up from the Discovery Center excursion last night.  My Buddha that food was good.  Except the dumplings on the 4th floor.  Those were… unpleasantly textured.

Best of track awards went to Founder for APS8, Susan Evans and Joel Pattison in MMP8, Tony Dunn in SAC1,  in TPR3, and Gabriel McGovern in UAD5.  Darn, I was hoping to see @tsand‘s session that I missed out on yesterday.  I think I’ll hit TPR3 and SAC1.  Tony’s is on picking a CMS (which we’ve already long since done, but hey, it’s @tonydunn), and Paul’s is the XSS scripting vulnerabilities session.

Credit to Tony for the lolcat presentation.  Dunn and the boys started off inwith failure in research.  Then continued the trend with more failure in purchasing in 2005.  One might suggest he is a fail magnet.  We shall see.  Advice one: STAY AWAY FROM COLLAGE.  It doesn’t help that Serena isn’t developing it anymore.  They started over inwith a win.  You gotta know your own workflows in order to pick a CMS that matches your needs.  They started the roll out this year.

Make sure you learn what a CMS will and won’t do.  Be realistic about the capabilities.  Involve the right people in the decision making process.  Identify the actual problems you are trying to solve.  Know your content processes (mentioned above).  A CMS is a tool.  A hammer helps you drive a nail, but it won’t do it without you swinging it.  “The more foolproof you make something, the better the fools get.”  Involve you administrators, tech staff, and content contributors when selecting a system.  Make sure that the problems that are being telegraphed to you are translating correctly, so that you can identify if a CMS can actually solve them.  For instance, out of date content can possibly be helped through a CMS with reminders, the actual issue might be training, staffing, and caring related instead.

Personal note, joking about Failblog images in the middle of Tony’s presentation results in projectile water.  Classic.

Make a list of initial criteria, and send to vendors.  Also check out cmsmatrix.org.  Then do an online demo and score features.  The make it a base requirement to have a sandbox set up to test in.  Hands on testing is not optional.  Do some user training and get feedback on their work processes.  Evaluate and approve.

Update 11:01AM ~ Rocking out in the cross site scripting session now.  XSS exploits are designed to play on the trust a browser has for information coming from a site.  It is not an attack on your site or server, it’s an attack on your users.  They made up just over 67% of all attacks in 2006.  88% of education sites have a high vulnerability problem.

XSS attacks are generally the first step in a larger attack.  They are platform independent, move fast, and can do everything from spam, to phishing, defacement, identity theft, etc.  Educational sites are critical in these attacks because we have a higher general trust among users and search engines.  63% of users will hit an okay button on a popup even if they are told popups are fake.

Three types of XSS: non-persistent or reflective (only active when a user is on a page and is social engineered into visiting, and requires the code to be in the URI), persistent or stored (put somewhere like a forum or social site), and local (attacks local files).  We’ll take some looks at some demos now.  There will be some videos from this session up at HighEdWeb later so you can watch those.  For the record, we’re looking at stuff on NBC.com and Cornell.

Fixing XSS: be paranoid, trust no one, and make many layers.  Do input filtering and validation, do output encoding, intrusion detection system (https://php-ids.org/), and tidy the output.  Tools: XSS-ME and Acunetix.