Basic Housekeeping - Plugging Obvious Security Holes In Web Sites - Paris Web2009
Upcoming SlideShare
Loading in...5
×
 

Basic Housekeeping - Plugging Obvious Security Holes In Web Sites - Paris Web2009

on

  • 9,381 views

My talk at Paris Web 2009 about basic web security and how to avoid opening your site for attacks.

My talk at Paris Web 2009 about basic web security and how to avoid opening your site for attacks.

Statistics

Views

Total Views
9,381
Views on SlideShare
8,986
Embed Views
395

Actions

Likes
6
Downloads
60
Comments
0

12 Embeds 395

http://www.wait-till-i.com 222
http://christianheilmann.com 117
http://developer.yahoo.net 18
http://searchlogger.net 14
http://it-corporate-cetelem.sfdi.echonet 6
http://developer.yahoo.com 6
http://icant.co.uk 5
https://developer.yahoo.com 2
http://www.slideshare.net 2
http://127.0.0.1:8795 1
http://translate.googleusercontent.com 1
http://xss.yandex.net 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Basic Housekeeping - Plugging Obvious Security Holes In Web Sites - Paris Web2009 Basic Housekeeping - Plugging Obvious Security Holes In Web Sites - Paris Web2009 Presentation Transcript

  • Basic housekeeping Plugging obvious security  holes in web sites. Chris9an Heilmann, Paris Web, Paris, October 2009
  • A few things to remember  about basic web security.
  • A bit of pimping... Gérer la sécurité de vos applica9ons web (Salle 1) Présenté par : Sébas9en Pauchet (WS Interac9ve),  Frank Taillandier (Académie de Toulouse) a.k.a. Dirty Tricks with @DirtyF
  • The most annoying thing  is that the dangers on the  web are underes9mated.
  • Reasons for aRacks: Spam injec9on. Iden9ty theT. Data mining. Botnet / Zombies / DOS
  • A lot of clever terms are  used in security. SQL injec9on  XSS  CSRF ClickJacking  Phishing
  • In the end, a lot is about  keeping your web  products clean.
  • This very much starts on  the server side.
  • Think about your folders.
  • Telling the world too  much.
  • You don’t want the admin  folders of your app to be  indexed by Google Search Engines.
  • Your system might tell  more about your site than  you are aware of.
  • Error messages are only  needed in produc9on ‐ on  live servers they can tell  more than you want to.
  • Keep your server setup  secure.
  • hRp://yoursite.com/index.php?admin=true hRp://phpsec.org/projects/phpsecinfo/
  • hRp://phpsec.org/projects/phpsecinfo/
  • Basic server measures: Turn off folder browsing. Stop bot indexing (robots.txt). Secure your setup. Turn off error messaging. Disallow remote file inclusion. Delete old and orphan files.
  • The next danger is blindly  relying on soTware.
  • Predefined backdoors and  passwords.
  • admin/admin admin/password default/default user/user preset/preset buil9n/buil9n
  • Plugins
  • Basic soTware measures: Change every password. Check for presets. RTFM. Keep Plugins up‐to‐date. Check for security holes. Don’t trust “easy setup”. Upgrade.
  • Front end security issues. 
  • This is not hard. Don’t trust any user data. HTML is not a database. JavaScript is not a secure data  container. Do not rely on JavaScript.
  • Frontend is public. If you comment, comment on  the backend, do not  “comment out” func9onality.
  • Frontend is insecure. Anything in the frontend is  executed and can be used to  steal all your cookies. (frames, images, scripts, links...)
  • Filtering hRp://us2.php.net/manual/en/book.filter.php
  • Whitelis9ng
  • Clickjacking.
  • Basic frontend measures: Break frames. Filter inputs. Whitelist inputs. Avoid hacks (expression()). Avoid URL assembling.
  • Our users
  • Social engineering.
  • SocEng basics: Show authority. Create fake need of urgency. Take over responsibility.
  • Condi9oning helps. :‐(
  • I approve  of this!
  • Social networks
  • Step 1: Log in yourself
  • Step 2: Get list of followers
  • Step 3: Set the trap
  • http://twitter.com/statuses/ user_timeline/codepo8.xml? count=200
  • Step 4: Lure his followers
  • None  of this!
  • Predictability
  • Basic people measures: Don’t allow for auto log‐in. Share security responsibility with the users. Avoid stressful interfaces. Be very open about your  communica9on.
  • Bot aRacks.
  • Captchas to the rescue? hRp://caca.zoy.org/wiki/PWNtcha
  • Bot aRack measures. Honeyponng. Timed interfaces. Cookie check / Crumbing. Spike detec9on.  OpenID / third party logins.
  • Nothing beats being up‐ to‐date!
  • None  of this!
  • I approve  of this!
  • You learn a  lot from logs.
  • No strength in numbers.
  • Check your posts.
  • And query terms.
  • Some not‐so sci‐fi ideas...
  • Guest passes.
  • oAuth
  • OpenID
  • Caja/ADsafe
  • Caja limits and  secures web  standards.
  • Caja vs. “HTML” ★ Custom aRributes ★ Custom tags ★ Unclosed tags ★ <embed> ★ <iframe> ★ <link rel=‘… ★ javascript:void(0)  ★ Radio buRons in IE ★ Rela9ve url’s
  • Caja vs “JavaScript” ★ eval() ★ new Func9on() ★ Strings as event handlers (node.onclick = '...';) ★ Names ending with double / triple underscores ★ with func9on (with (obj) { ... }) ★ Implicit global variables (specify var variable) ★ Calling a method as a func9on ★ document.write  ★ window.event ★ .onclick ★ OpenSocial gadgets.io.makeRequest return JS
  • Caja vs “CSS” ★ * hacks ★ _ hacks ★ IE condi9onals ★ Insert‐aTer clear fix ★ expression() ★ @import ★ Background images in IE
  • Throwaway logins.
  • New challenges.
  • Social Network aRacks
  • The mobile web.
  • Camera access.
  • Loca9on based services.
  • Biometric recogni9on.
  • Right now things are not  safe.
  • But you can help making  the web safer.
  • Keep it clean, keep it up‐ to‐date and be alert.
  • MERCI!   Chris9an Heilmann   hRp://wait‐9ll‐i.com    hRp://developer‐evangelism.com   hRp://twiRer.com/codepo8