stream of thought on the #tekx “bad guy for a day” tutorial. writing may resemble note-taking…because it is.

K, trying a bit of live(ish) blogging. This will be interesting since this will be stream of thought on the tutorial as it goes on.

Todays tutorial is given by Arne Blankerts.

We’re starting off with an over view of websecurity and what we’ll be doing today. Looks like I missed questions, good thing I didn’t have any.

We’ll be getting source to look at, makes me wish I wasn’t lazy and had set up an environment.

Starting off with types of security. Transport layer,infrastructure, data warehouse,interface design, user level and application level…those sort of things.

Remember to secure your infrastructure. Anecdote about a setup with default root of database was given. Keep in mind how you train users. Example error alerts training people to accept errors as ok and to click through.

Infrastructure

Single server vs multihomed. This will be intersting. Requires trust with ISP. One problem is session storage is set/written by default. A hacker can access the session data of other sites if this isn’t done correctly.

Another thing is to only set up necessary services (webserver,database,3rd party services).

User interface

Important since it’s what you use to communicate with the user. Basic usability considerations such as submit, clear, continue. Icons are interesting because of l18n/i10n.

User level

Need a high sense of security. Standard error messages are dangerous b/c of the information leak and it’s just sloppy.

Attack vectors

Mass mails, social engineering,script-based (software stack exploits on browsers, plugins), backend exploits (php,webserver,database). Social engineering examples like USB sticks and windows autorun. Don’t need autorun, you can seed within a picture. (Mental note, run any found USB sticks in a vm…)

XSS

Modifying a website with injected code. Use chained xss to create trust, create fake news are ways you can manipulate content.

Level 0 (DOM) attacks are based on js only in the browser. They’re temporary and require a crafted link that includes the xss code.

level 1 (non persistent) also requires a crafted link, based on generated server output.

level 2 (persistent) is saved on the backend.

Always remember to filter input and escape output. Basically assume all user input is malicious.

Sessions and cookies

Sessions allow for logical links and are fairly unique. Big use is for authentication. Problems include session is stored remotely (untrustworthy source,may be outdated, user might have changed). PHP doesn’t really validate an ID (may contain malicious characters or may not point to an actual session)

You should validate id manually and generate new session ids. You should change session id after

• user login
• permission change
• restart of session

Disable any transport other than cookies

• disable session id via URL
• use http only cookies

Disable trans_sid.

CSRF

Also known as “session riding”. This is an abuse of active sessions on 3rd party sites and is a hugely underestimated problem. Can embed in various places, such as iframes or images or use javascript or xss. Typical targets are banks or bidding platforms.

DO NOT USE $_REQUEST. You should deliberately use your expected source ($_POST, $_GET,$_COOKIE). Though you should avoid $_GET where possible to raise the bar of work a hacker needs to do.

Introduce single-use tokens by adding an “anti-csrf” hidden field. Of course, you should make sure the tokens aren’t predictable and bail out on missmatch.

Wrong measures include HTTP-Referrer checks because Referrer can be easily faked, isn’t a requried header field and can be automagically corrected.

sql attacks

• string vs integer
• escaping (union select)
• comments

SNIFF (Social Network – Insecurity For Friends)

Source code demo. @frozensolidone was first guinea pig to make sure it was safe.

Beware of redundant information such as hidden fields with a user id when you already have that information in session. Reminder to check filecheck types. Reminder about using $_GET information in your output. Attack code can have filler that looks meaningful that causes the actual attack to scroll out of the location bar.

example: example.com/?AuthCode=3as;dlfk32;lkaflsaf&message=attack_vector_tags_inserted_here.

Talking about password strength and the need to enforce strong passwords.

Another consideration is placing code outside of the document root.

When filtering and escaping, remember to not repair user mistakes.

Note that the sample source code is the worst way to do it so if it looks like you do things that way, you’re probably doing it wrong.

sildes at http://talks.thephp.cc

In the end, it’s good to be paranoid. The paranoid survive.

Related articles by Zemanta

• CSRF Attacks and Forged Headers (michael-coates.blogspot.com)