Kirk Jackson's Page of Words - Security

WDCNZ Conference - Web Security: Get a Head(er)

Kirk Jackson — Thu, 14 Jul 2011 01:52:31 GMT

Today I'm presenting at the awesome WDCNZ conference, organised by Owen and the fine folks at Xero.

The talk discusses some of the new browser features that will help to protect you from XSS, man-in-the-middle and other attacks.

Please download, and send through any feedback or questions: KirkJackson-WDCNZ-GetAHeader-online.pdf (1.35 MB)

New Zealand ALM Conference - Thinking Securely from life to cycle

Kirk Jackson — Wed, 06 Apr 2011 10:40:13 GMT

Andy and I presented at the first NZ ALM conference today -- a conference covering all aspects of the application lifecycle, and use of the Visual Studio ALM suite of tools.

Our talk covered the Security Development Lifecycle, and gave some 'motivating examples' of different recent hacks, exploits, or just plain quirks that demonstrated how thinking about security at each stage of the lifecycle can help protect the security and privacy of your users, businesses and their data.

Here's the presentation, including links to useful web references:

2011-04-06-NZALM-KirkJackson-AndyProw.pdf (4.4mb)

SharePoint Conference NZ - Is your SharePoint under threat?

Kirk Jackson — Thu, 17 Mar 2011 22:42:33 GMT

I presented at the NZ SharePoint conference yesterday. It was a pretty impressive event - kudos to Debbie and the organising team.

My talk was split into two parts: what are some of the risks in running a SharePoint site; and how can you protect against them.

The risks I covered were cross-site scripting and malicious file uploads - MIME sniffing in IE, the recent MHTML attack and the ever-present risk of malicious PDF documents. The key takeaway is that any file uploaded could be malicious, and to think of how to mitigate those risks.

In the 'protection' section, I covered some SharePoint development best practices and stepped through SharePoint specifics on how to protect against XSS and CSRF. SharePoint has some pretty good protections built in the box, but if we're building our own web-parts we need to be vigilant.

The presentation should shortly be available from the conference website, with a video in a month or so. If you've got any questions please feel free to email me or get in touch.

2011-03-17-NZSPC-KirkJackson.pdf (2.9 MB)

Cheers,

Kirk

Recent talks - I know what you did last summer

Kirk Jackson — Wed, 09 Mar 2011 08:17:00 GMT

This month I gave a similar talk to two user groups. The OWASP Wellington (and Auckland over video conference), and the Wellington .NET user group both invited me to speak on: "I know what you did last summer; The latest from the world of web hacks".

This was a fun talk to deliver. The focus was on recent web 'hacks' that had occurred in the past few months (I used a pretty general definition of 'hack'), but the main discussion was around the lessons that we could learn from these issues and what we could draw back into our own projects.

I think this talk had the most amount of interaction out of any of my previous talks. There was lively discussion about what the root cause of the problem was, whether it was even fixable at all, and we lamented the effects of 'users' :)

Since the .NET talk was a superset of the OWASP one (it was longer), I've included those slides below:

2011-03-09-WellingtonNet.pdf (2.07 MB)

Thanks for coming!

Kirk

ASP.NET Vulnerability - Slides

Kirk Jackson — Wed, 29 Sep 2010 08:25:39 GMT

Thanks to those user group members and Xero partners that came along to our talk today.

We covered the two vulnerabilities released last week, the workarounds, and the patches that were released this morning.

Here are the slides: KirkJackson-PaddingOracle.pdf (641.14 KB)

All ASP.NET applications are affected. The best thing to do is install the patches released this morning.

Problem & bulletins:

Security bulletin MS10-070

Useful info on ScottGu's blog

Forum about the security vulnerability

Video of a site exploit, even with the workarounds applied

Patch:

Scott Gu's writeup of the patch

Post-mortem of the patch - Marc Brooks

How to configure the new patched features

Research:

Juliano Rizzo and Thai Duong and their POET tool

Padbuster tool (including a great writeup of Padding Oracles)

ASP.NET vulnerability - briefing in Wellington this Wednesday

Kirk Jackson — Mon, 27 Sep 2010 09:08:47 GMT

If you're in Wellington this Wednesday and you develop, maintain, manage or host ASP.NET or SharePoint websites, please do come along to hear about the security vulnerability disclosed a week ago:

http://www.dot.net.nz/Lists/Events%20Calendar/DispForm.aspx?ID=321

10 things YOU are doing wrong!

Kirk Jackson — Wed, 01 Sep 2010 04:18:01 GMT

Here's the presentation I delivered at the Auckland Code Camp 2010. It covers 10 things that I found when surveying attendees websites :)

10 things YOU are doing wrong! on Prezi

Dean Carter: Ramblings of an ex-QSA

Kirk Jackson — Thu, 15 Jul 2010 04:47:41 GMT

Used to be a QSA (Qualified Security Assessor). There are now 8 in NZ.

The QSA wears the risk and signs you off for PCI compliance.

There are no silver bullets for PCI stuff.

"It's a hell of a roller-coaster ride"

He has seen 2.5 million credit card numbers in NZ, in the clear, in many website databases.

One guy Albert Gonzalez compromised 170 million credit cards across many large corporations.

PCI requirements:

"Protect stored data": 79% of orgs fail on this.

PAN (account data) must be unreadable when stored.

You can never store mag stripe data.

"Track and monitor all access to network resources and cardholder data"

"Develop and maintain secure systems and applications" - 56% of organisations fail on this

Rant:

1. Card holder data gets everywhere

2. Keep test and development environments out of scope. Don't use real live data in them.

3. The good: payment gateways and companies that handle cards - they do a good job. They outsource to experts.

The bad: small merchants with a few transactions. Cheap website with cheap hosting. Easily compromised.

The ugly: corporates. Great staff but don't make any progress.

If you're a merchant: find a compliant service provider.

4. If your a service provider: code well, make a noise about it. Make your solutions easy to assess for compliance. Keep in touch with your acquiring bank.

5. You need to evolve your security to address risks. You are allowed to exceed PCI standards.

6. New VISA best practices: you don't need to store the PAN any more, rely on your service provider to do it.

7. Do it properly, or don't use credit cards. Support your developers and give them training.

8. Storage of card data: Challenge it - why does the business need it? Get rid of old cards if you don't need them.

9. Checkbox security - don't just check the boxes. Exceed them.

10. OWASP top 10 - adopted by PCI DSS.

Two most useful links:

www.pcisecuritystandards.org

www.owasp.org

Parting thoughts:

- Use OWASP as a tool

- Don't confuse compliance and standards with security

- Chop up your credit cards!

Questions:

Why did you give up being a QSA?

It was really stressful

When collecting info and passing it on to a payment gateway, do you require an audit?

Different QSAs treat it differently. He believes the webserver is in scope if it's taking the card data. New version of standard coming out in October that may address in-memory stuff.

Why stop using credit cards? At least you get protection, unlike if you use debit cards?

Dean uses a low-value debit card.

How does PCI deal with it if you're using third-party libraries?

Payment application DSS will kick in if you're using it to resell.

Quintin Russ / Mike Jager - Hosting and Security

Kirk Jackson — Thu, 15 Jul 2010 04:24:29 GMT

Hosting and Web Apps
The Obscurity of Security

Quintin from SiteHost and Mike from Web Drive cover horror stories they've uncovered in website code when they've been rung up to fix something.

Security used to be the domain of systems admins and hosters, but developers have added more fancy features.

Website owners and developer blame their hosters when their sites are defaced.

What if security isn't part of the spec?

Make it part of the spec.

(Shift jobs if management won't let you make it part of the spec.)

Security starts early: Planning and design phase

- Research, talk to security people
- Get your team some security experience
- Reduce the attack surface
- Keep it simple: Don't build a CMS for a 5 page site
- Don't have an admin area, or use defense in depth to protect it

Not all apps are equal:

- Sometimes buying is better than building
- Everything has security holes
- Pick something good
- How does vendor approach security?
- Check the apps security history:
- If there are no holes, beware. If there are silly problems, beware.

RTFM:

- Read the OWASP top 10
- Read the OWASP books
- Read the install documentation and follow the "After installation" docs.
- e.g. Think about what you do when you unserialise stuff; don't trust untrusted user data

Development:

- Attack surface reduction
- Validate all your input
- Use source control, and know how it works.
- Watch out for rolling .svn, .git, .cvs directories: might show directory lists, source code, usernames
- svn checkout is an invalid installation method
- Look at all the files that are there! Especially free / open source apps you download

Data management:

- If you don't need it, don't store it
- If you need to keep it, how do you need to access it?
- Hash (with a salt), don't encrypt
- Keep production and development seperate
- Keep tabs on your data - size, growth rates, is data used by the code? Get rid of it.

Password strategy:

- Don't reuse credentials
- Weak usernames and passwords for db - common to see dbname = username = password
- Watch out for old staff members and old passwords

Filesystem security:

- Watch out for apps that use /tmp and friends, or require special directory permissions
- Learn how to chmod correctly. x is good enough for directory traversal.
- Watch out for log files in web root
- Beware test files eg phpinfo
- Don't leave old crap on your filesystem: Session files, template caches, zip files

Deployment:

- Automate as much as possible
- Don't blindly follow installation instructions
- Read them when you select the software, and understand what it's doing
- Don't use hosting control panels if you don't need them - they have high level access to the underlying system, and greatly increase your attack surface
- Use SSL for the content not just for the login pages
- Keep your websites separate - different trust level = different credentials

Backups:

- Keep your own backups - don't trust the providers ones. They protect from a catastrophic failure, and you could lose 12-24 hours of data
- Test them before you need to use them

Clouds:

- Don't ever use remote includes - including some third party code in your app!
- Minimise remote resource usage:
- How does your site react if the remote resource is gone?
- Take your own copy of AJAX libraries
- Do you need third party analytics for everything?
- Outsourcing data storage: What data are you uploading? Where is it hosted? Is it safe? Who has access to it? How are backups stored, and how long are they retained?

Software lifecycle management:

- Have a process for decommissioning, make sure you delete data and files that aren't used
- Make sure software is up to date
- Who monitors upstream releases? How quickly do you make patches? Who makes the call?

Monitoring:

- Monitor changes to your website content and uptime
- Check external access. Has your whitelist stopped working?
- DNS: Remember that DNS is an external dependancy. Has your domain been hijacked?

Politics:

- Make security a part of job description - managers and developers need to make security a priority and make it part of KPIs
- Get buy-in from non-technical staff

Talk to your hosting providers:

Talk to their security guys well in advance. Make sure your specific requirements are getting through to the technician who is doing the work (don't trust the salesperson).

Remember: It's your job to make sure it's working

Questions:

Including KPIs is a good thing, but you need to give developers the time to learn.

Graeme Neilson / Kirk Jackson: Tales from the Crypt0

Kirk Jackson — Thu, 15 Jul 2010 03:25:18 GMT

Thanks to everyone who came along to our talk at OWASP NZ Day 2010 today.

Also, a big thanks to the Wellington .NET user group crowd that came last night to listen to our practice run -- you'll be pleased to know that we dropped the discussion of hash extension attacks :)

Here are the slides for your downloading pleasure: tales-of-the-crypto.ppt (3.79 MB)

Metlstorm: Low Scuttling Chillicrab

Kirk Jackson — Thu, 15 Jul 2010 01:48:11 GMT

Adam is one of the organisers of Kiwicon, and has presented on this topic in Singapore.

Using tools to capture / probe network traffic.

If you compare to app/data recon tools like Maltego, network recon tools aren't as start of the art.

But... if you own the networks under this new fangled cloud stuff, then you own the whole environment.

It's hard to map out, search and investigate >= Class A

At the moment, only big countries can do that sort of investigation. Apparently countries are gearing up for 'Cyber Wars'.

But, individuals and corporates can get involved in the same activities of cyber-war or cyber-terrorism.

Scanning, pinging and trying exploits doesn't scale well - you have to do a lot of work and get lots of false hits.

You might get owned randomly - it's cheap to own more targets, and then figure out what to do with it later.

Targeting:

It's hard to target large numbers of IP addresses. The current tools can't scale to those kinds of numbers (and the pay services will get really expensive).

lowscuttlingchillicrab.com

So he built a geo-targeted network recon data acquisition system with a web interface, and scanned all of NZ and Singapore for conferences.

An interface to search over data.

"This is a highly secure router, stay away" - the open telnet port tells us so.

Cool things it does:

Searches over certificates
Screen captures remote desktop screens
Good for targeting: finding particular applications / devices / protocols
Good at finding other assets owned by a company outside of their own netblock
Helps us understand how many vulnerable things are sitting out there

The internals of the tool:

Version 1 was just to see how plausible it was to scan large chunks of the internet. Used lots of glued together tools like nmap etc.

Version 2 is now a simple python script that has been optimised for acquiring the data by scanning a whole country block over certain ports.

A few billion rows of data - use MongoDB to store data. Erlang, RabbitMQ, Python, Celery MQ, Python / Django frontend, GridFS distributed filestore.

Target selection:

How do you define what a country is? Is it domain names ending in .nz? Netblocks announced at peering exchanges? Address registry allocations? GeoIP?

He chose GeoIP as it simplified things - but misses out on .nz stuff hosted overseas.

Acquiring data:

Custom-tuned protocols to limit rates, fire up application to capture details for different protocols.

About 1.4B rows per complete scan of NZ and Singapore.

Need to optimise for search / retrieval as that's the primary use once the data is acquired.

Data mining:

Look for old boxes, boxes with self-signed certs, certain switches, domains etc.

Singapore: 377k boxes that talk HTTP - more than the number of live systems. 14k cisco boxes. 12k open RDP (one with background of Commonwealth Bank of Australia :))

IDS Avoidance:

He's not actually carrying out any intrusions. Only collecting banners, and complying with what they say.

IDSs don't necessarily detect them - only 7 complaints to ISP in NZ, and one funny one in Singapore.

People are watching - DNS PTR backscatter gives an idea of people watching and resolving domain names for IP address.

Portscans aren't very interesting these days. People notice, but don't do anything.

But not good for:

If you notice mis-configured systems, it's hard to do anything about it.

Giving it as public / bad guy access would be difficult and cause problems.

What about Shodan?

Scan whole world for 4 ports (21, 22, 23, 80), but not as many hosts or depth of coverage in NZ.

Sells commercial access to exported data.

What does it mean?

A search engine over this data makes it very powerful.

It's not that hard to do this sort of thing. It's probably already being done by military or crime industries. Cheap compared to a drug submarine :)

Questions:

What did the abuse mails say?

One from a Uni, two or three from an ISP and they noticed scanning of the SIP voice customers. A few of ZoneAlarm type people noticing.

Scanning boxes: Where were they hosted? Bandwidth out?

Domestically peered, gigabit to APE. It's not really bandwidth constrained, it's constrained by politeness. Turned off state tracking for outbound connections. Could probably do the whole country in 2 hours if you cranked it up, but would cause problems for people.

Paul Craig: What to do when you get pwned?

Kirk Jackson — Thu, 15 Jul 2010 00:00:10 GMT

Paul Craig works at security-assessment.com as a forensic investigator.

Forensic investigation: Fact-based investigation - must be reproducible and not based on anything subjective.

If you're going to get hacked, it will start at your web app. Firewalls generally stop all other traffic.

Treat all results as possible legal evidence - could be used for murder etc cases. Evidence could be used to allow police to arrest a suspect.

Most computer crimes in NZ will be tried under property law with a judge and jury.

All evidence may need to be provided to defendant to cast doubt on the evidence. How was it collected or analysed?

Common things customers say:

- Assumptions
- They only compromised one server - assume it has happened more than once
- We already dealt with it - probably destroyed all forensic evidence (could come back to bite in the future)
- It's too hard / not my problem

What to do when there's an incident:

How you act makes all the difference. Smooth engagements and do things as fast as possible.

Need a single point of contact for all security incidents within an organisation.

Appoint an incident response team - includng someone with internal clout, legal support.

Find a forensics supplier in advance. Don't leave it till when there's an incident.

It's a specialised industry, and you shouldn't do it yourself.

Media:

Media love a hacking story. This makes things stressful.

You need a bottom draw letter pre-written that you can give to the media. Get it signed by the CEO now.

Technical incident response:

Treat with urgency, gather incident team together in a secure location.

Get incident responder into the system as soon as possible to get current connections, arp caches etc.

- Disable scheduled patches, updates, restarts
- Unplug from internet / firewall it
- Leave the server powered on
- Put a big sign "Do not touch"

Within a day or less if possible.

Police reports:

If you have evidence that a crime has been committed, or something could be committed (e.g. fraud), file an incident report with police. As much evidence as possible.

Will you catch them?

If NZ / AU - likely.

If UN / NATO, possible but involved IPTF task force.

Other country: very slim chance of catching them.

When don't you have to file a report:

No loss of finances, no increase in fraud risk, no chance of repurcussions / fines.

How to do forensics:

Paul then talked about how security-assessment.com do forensics testing. Take-away: it's hard, and in order to provide evidence in court you won't actually be able to do it yourself.

Examples:

Paul gave examples of when they'd be engaged with customers. Problems encountered:

- They knew they had been hacked, but hadn't told each other
- Meeting in insecure places
- Taking too long to figure out what to do
- Companies that don't know how to respond
- Assuming evidence has been destroyed already

Without senior executive support, nothing will happen. Forensic and technical response isn't a technical problem: it is an entire business problem.

Take-home:

Sooner or later, you'll get hacked. When it happens, take it seriously.

Prepare for that incident straight away. Figure out what you'd do?

Stay cool when it happens, follow the game plan.

Never assume anything!

Questions:

How do you deal with situations where the hacked website needs to be back up in 10 minutes? So you don't have time to do forensics?

- Bring up a DR server if you have a safe backup.
- If it's compromised, you have to take it off immediately if someone is on that server at that time

How do you deal with virtualisation? When you don't have physical access to a machine?

- Can get all active memory and disk onto a disk
- Can take the entire VM snapshot and rebuild into a real computer again

What about if it's a cloud provider?

- Probably have no access to get an image. Comes down to whether we can get that access.

Does a live image impact the integrity of the evidence?

- Hash the evidence as soon as it is taken, so we can prove the image is unaltered.

If hacker uses anonymity services like tor / proxies?

- Often there's one request where they connect back directly.
- Often there's still some fragments of evidence remaining.
- Might be able to find out what they did, but not necessarily who did it.
- "Your credit cards have not been touched"

Roberto Suggi Liverani - Defending Against Application Level DoS Attacks

Kirk Jackson — Wed, 14 Jul 2010 23:37:58 GMT

Roberto's talk covered application-level vulnerabilities, and gave some ideas on how to plan for them, how to react when they happen, and how to recover from them.

Most denial of service attacks have traditionally covered the layer 3 or 4 (i.e. the transport or network stack), but Roberto has seen attacks against applications and web service layers.

Can lead to increased use of resources like CPU, network

Root causes:

- bug
- application logic open to abuse
- session level attacks

Examples:

PHP: Can create an unbounded size object in code

Failure to release resource: DB exception doesn't close connection. Attacker can cause app to open up lots of DB connections and deny service.

Sesion related: storing lots of session objects that consume resources, so attacker can target this to exhaust server resources.

User input as a loop counter: If the user can control how many times an expensive operation is performed, it can cause the app to do lots of demanding work.

=> Put in some limits, don't allow the user to set in their code.

Regular expressions: Certain input may cause lots of passes through a regular expression, causing lots of CPU to be used.

Other web problems can amplify DOS effects (XSS, XSRF, SQL injection, large file input)

Recommendations:

- Input strict validation and filtering
- Handle exceptions and properly release resources
- Set limits for:
- Session related objects
- Token expiration
- Object allocation
- Loop counters
- User registration - captcha
- Concurrent session tokens per IP address

- Testing your web app
- Test Regex, database queries
- DoS and stress testing
- Security testing

XML attacks:

There are lots of attacks against XML or web services.

Recommendations: don't use customised XML parser, input validation, use an XML firewall, limit the sizes of input messages, disable external DTDs.

Webserver attacks:

Attacks to use up all the threads on a webserver, or slow down the processing so the server can't process other requests.

Recommendations: Apache and IS have modules or configuration settings. Make sure you test the changes.

Database attacks:

Make the DB do more work than they should. E.g. cause a slow scan over a whole table, or avoid caching layers.

Recommendations: Input validation, captcha or user limits, only let authenticated users perform slow queries, use caching layers.

If you are under attack:

Be prepared, have a plan, simulate it often.

When under attack:

Is it real? What is the target? Is the target critical?

Reacting:

Several methods: slow down the attack, deflect it, drop connections, escalate to authorities or other nefarious ways to stop botnets.

Recovering:

Meet up to debrief as soon as possible afterwards. What lessons were learnt? Update incident plan.

What was the root cause? What if it happens again? Provide all data to law enforcement.

Conclusion:

No generic solution to DOS.

If offered a DOS solution product, look carefully before committing.

Start networking with people that can help you.

Brett Moore: Don't try this at home

Kirk Jackson — Wed, 14 Jul 2010 21:59:45 GMT

Brett presented a talk on some of the "Not so common code vulnerabilities".

The theme of his talk was that we shouldn't trust user input.

My notes:

A security vulnerability in an app - a weakness that allows a user to perform an action that was unintended.

AppTrends graph (cenzic.com) - input validation is the cause of everything (XSS, SQL injection, etc)

Frameworks won't protect you (e.g. .NET, PHP, Java frameworks).

Frameworks can promote bad practices, or have bugs in them themselves.

- Spring Framework http://blog.o0o.nu/ - override class loaded
- Struts2 - execute arbitrary java code

Examples of problems:

Trusting filenames / urls from the user

Using 302 Redirects as a security measure - returning secure

content below the redirect by mistake

Captchas: Tell whether it's a human or computer. Bad implementations where people have rolled their own and make it easy for computer to answer

Online shopping: Response from DPS comes in a browser redirect, so you can intercept it, and add extra stuff to the shopping cart after paying, but before the website thinks the order is finished.

Flash: Parameters for a flash movie can be entered in the url as well. Movie hosted on our site can end up displaying images or other content from our attack website.

Forgotten password: Stored proc truncates email address to 100 characters when looking up the user, but application uses the whole string. This can lead to an attacker receiving the forgotten password email.

Java object serialisation: Object is serialised into a cookie using Base64 encoding. Ooops: It contains something sensitive like a password.

PHP app in a security appliance used by a .mil: Shell out to a system command using a url parameter passed via an unauthenticated user.

Cookies: storing security data in a cookie - example of LoginAttempts - an attacker can modify the cookie to their hearts content.

Cookie: remember me functionality - store random token in the database and send it to the user as a cookie, so they can log in automatically. Vulnerability: flawed if null was stored in both the db and the cookie.

Lesson:

Never trust the users input

Input validation is the key.

You can use hidden form fields or cookies, as long as the backend input validation is secure. You can't trust that the frontend is doing things correctly.

Backend should:
- Validate the data
- Ensure the user is authorised to access the data

Data comes in many forms (upper / lower case, encoded etc)

- Decode the data, or reject it if a normal user wouldn't send it

Ensure data conforms to the correct format
- Check length, type, min / max values
- Alphanumeric / valid date only

Reject invalid data, rather than attempting to fix it up.

Beware writing your own data sanitisation functions - needs to be well tested and document. Use OWASP or language features if possible.

- Easy to write bad sanitisation. Examples of bad url testing,

XSS works without script

Takeaways:

- Review your code. Have "Code Review Parties"
- Have peer reviews
- Have standards, and stick to them

Questions to Brett:

Should we still trust CAPTCHA?

Still effective at the moment, but can be broken.

OWASP NZ Day 2010

Kirk Jackson — Wed, 14 Jul 2010 21:54:01 GMT

I had fun attending OWASP NZ Day 2010.

There were 6 great sessions - plus Graeme and I presented a talk on encryption, and how to develop applications using encryption:

Brett Moore: Don't try this at home
Roberto Suggi Liverani - Defending Against Application Level DoS Attacks
Paul Craig: What to do when you get pwned?
Metlstorm: Low Scuttling Chillicrab
Graeme Neilson / Kirk Jackson: Tales from the Crypt0
Quintin Russ / Mike Jager - Hosting and Security
Dean Carter: Ramblings of an ex-QSA

I came away with that feeling of satisfaction where you know you've learnt lots, but haven't had time to digest and process it all yet. Some of my immediate takeaways are:

Input validation is still a big area of problems in most apps
Application bugs and inefficiencies can be vectors for denial of service attacks
If you get pwned, hacked or DOS'd, you need to have a plan of what you're going to do to recover, and if there's a chance that you need law enforcement involved, you need to get a forensic analyst involved very early on (preferably in advance)
There are lots of computers on the internet in NZ, and lots of them have obvious vulnerabilities. No-one is doing anything about this (at least, no-one good is doing anything about this!)
Bad development practices lead to problems in the hosting environment. App and deployment security problems live on
Credit cards are the devil, and should be treated as such :)

Thanks Roberto and Lech for organising, I'm looking forward to next year!

Kirk

Syntax support for HTML Encoding in ASP.NET 4

Kirk Jackson — Fri, 09 Oct 2009 09:00:18 GMT

To prevent cross-site scripting, it's important to encode data before outputting it.

Up until now, it has been quite hard to ensure you're encoding everywhere throughout your app.

It's great to see the new syntax in ASP.NET 4 to automatically encode:

First Name: <%: Model.FirstName %> Last
Name: <%: Model.FirstName %> <form method="post"> <%: Html.TextBox("FirstName") %> <%: Html.TextBox("LastName") %> </form>

(From Phil Haack's blog)

This means that for all new web applications, you can build using <%: %> instead of <%= %>, which is great for ASP.NET MVC applications where that syntax is common.

For older applications you will be able to opt in to the new encoding syntax, but your old code will keep working exactly as it already does (perhaps insecurely, if you're not encoding!)

Here's hoping that we'll be able to replace the standard HtmlEncode with the AntiXSS goodness I described here:

What is encoding? Cross site scripting and the AntiXSS encoding methods

Kirk

Code Camp Auckland 2009 - Development | SQL | Security

Kirk Jackson — Sun, 30 Aug 2009 11:17:02 GMT

Code Camp is less than two weeks away!

If you want to catch some free sessions on the state-of-the-art in .NET development, SQL Server and developer security then sign up for Code Camp Auckland 2009 now.

Code Camps are non-profit, and organised by members of the local developer community. This year the Auckland Code Camp is the day before TechEd (Sunday 13 September), so we've managed to nab a few great speakers on their day off to present to us.

It's the biggest Code Camp ever - over 14 hours of sessions across 3 streams from 10am till 5pm:

Development...

What's Happening in .NET Languages and Why Should You Care?
.NET on the iPhone and Beyond
Behaviour Driven Development
Domain Specific Languages
C# 4.0 new features
Silverlight with Prism
Becoming Certified
Lightning Talks
and more!

The latest and greatest in development topics, by the people that know!

SQL Server?

SQL Server Virtualisation Best Practices and Recommendations
SQL Server Analysis Services and Gemini
Query Optimization and Query Tuning
Understanding SQL Server Indexing
SQL Server Maintenance

Training and guidance from the best SQL trainers in the industry!

Security!

Secure Development Lifecycle and Threat Modelling workshop
Secure Coding Practices

We are lucky to have Michael Howard, author of Writing Secure Code and 24 Deadly Sins of Software Security giving a free workshop for developers, architects and team leads on Threat Modelling and the Secure Development Lifecycle. This will be followed by a session on how to write secure .NET code.

Auckland has never seen such an awesome free event!

Presenters that are offering their time include Greg Low, Nicholas Dritsas and Auckland's Alex Henderson of Architecture Chat fame.

To cover the costs of the event, we have the help of our generous sponsors: Microsoft, Datacom, Intergen, INETA and Xero.

All that's left for you to do is to visit the website for more details, and sign up now!

See you there on Sunday 13 September,

Kirk

OWASP NZ: PCI-DSS for OWASP Practitioners: Dean Carter, security-assessment.com

Kirk Jackson — Mon, 13 Jul 2009 03:46:55 GMT

If you store, transmit or process credit card data, PCI applies.

How can OWASP help you with PCI compliance?

Credit card data:

Primary Account Number (PAN): Can store it, but protection required.
Can never store the CVD 3 digit number or mag stripe

Card data attacks have been increasing in sophistication.

PCI-DSS affects anyone who transmits, processes or stores payment card data. E.g. merchants, service providers (e.g. Paymark, DPS).

Look at 12 requirements of PCI-DSS (firewalls, storage etc)

Protecting stored data:

You must not store sensitive authentication data. Principle: if you don't need it, don't store it. Consider outsourcing, truncation, tokenisation.

Tokenisation: Replace PAN with a unique identifier "token"

Truncation: don't store all the data (e.g. first 4, last 4 digits)

Encryption: Encrypt at point of capture, only decrypt when required, use industry standard encryption, protect your keys.

Developing secure applications / Test app was built securely / Use secure coding guidelines:

Standard OWASP guidelines

Annual risk assessment:

Every year, new threats will affect your site. Go and re-assess against the new threats.

Fixing legacy systems: make sure no old data is lying around.

Real life example: it's very easy to mess up (example of reverting to old code)

Parting thoughts: achieve, maintain and validate compliance. Secure development is a key activity. OWASP is a good source. Reduce storage of PAN data.

OWASP NZ: Application Bug Chaining: Mark Piper, Catalyst IT

Kirk Jackson — Mon, 13 Jul 2009 02:57:28 GMT

Bug chaining - an idea that hasn't really propagated yet.

How do we rate how severe a bug is? Consider how easy it is to exploit, where it is accessible from (client-side, server-side, internet, local, mass exploitable, targeted exploit, etc).

Audience attempted to rate the severity of a couple of bugs:

SQL injection on authenticated site -> medium/high
File upload php files on authenticated site -> high/critical
Local file disclosure -> medium/high
XSS - reflective, authenticated -> low/medium

Is attacker considered 'authenticated' once there is an XSS attack? Any subsequent attacks can be treated as authenticated.

When you join together the XSS bug with the file upload bug, then it's critical!

Bug chaining: taking multiple bugs and chaining them together to create exploitable vulnerabilities. Instead of looking at each individual bug, look at how they can be combined together.

There are now frameworks to help chain together exploits - and this is how a lot of worms now work.

Recent examples of chaining exploits: PHPMyAdmin <= 3.1.3; SugarCRM <= 5.2.0e - compromise server through 3 bugs together.

How to deal with this? CVSSv2:

Common Vulnerability Scoring System v2.0
Scoring system for assessing bugs
Considers exploit complexity, application location, authentication, target likelihood etc
Can be very complex, time consuming, difficult to follow

"You can explain this stuff all day, but when network admins actually see you do it, that's when they understand" Brett Moore

VtigerCRM - large open-source CRM system which fixed problems with a security patch, but don't link to the fix (and haven't installed it themselves!).

He wrote a BeEf module for VtigerCRM that can run as an auto-run module (took less than 2 hours to write):

Chains file upload and XSS bug to upload a malicious PHP script to start a command shell
Connection is from server to the attackers machine, so user doesn't need to stay connected

Summary:

Don't look at severity of individual bugs - need to look at how bugs can be joined together.

Understand the bugs.

Follow the OWASP coding and testing guidelines.

Tools:

BeEf - command console for an attacker to run script on the client computer. Modular list of exploits, and control multiple victims. Autorun modules to automatically execute modules within 1.5-2 seconds.

OWASP NZ: Exploiting Firefox Extensions: Roberto Suggi Liverani & Nick Freeman, Security-Assessment.com

Kirk Jackson — Mon, 13 Jul 2009 02:19:53 GMT

Firefox extensions: They're just software, like ActiveX. Extend, modify and control the browser.

Firefox extension points:

XUL: XML user interface language
XBL: XML Binding Language - logical behaviour of widgets
XPCOM: Reusable components, interface to file system etc.
XPConnect: Allows Javascript to connect to XPCOM
Chrome: Special browser zone that is fully trusted by firefox - code is fully trusted, has access to filesystem, user passwords etc.

Mozilla security extension model is non-existent. All extensions are fully trusted by Firefox - no boundaries between extensions, they can modify each other without the user knowing. Can be coded in C++ and subject to memory corruption etc.

Extensions are very popular (billion downloads) and can be found everywhere - social networks, search engines, software packages (skype, anti-virus), anti-phishing toolbars.

Biggest problem is the human side of things - Addins.mozilla.org recommend extensions and add a 'recommended' icon next to them. Extension source code isn't read by third parties ("It's not the linux kernel").

There's no protection from an extension with a security problem, it will bypass any other phishing / malware protection extensions.

Extensions aren't signed (even the Mozilla ones), so we can't rely on people checking signatures.

If an extension is originally trusted, then subsequent updates won't go through the same review process.

No current guidelines for testing a Firefox extension, so security-assessement.com havce come up with their own methodology (whitepaper to be released this year, early next year):

Isolated testing: Only test one extension at a time, on different OSes with different Firefox versions.
Information gathering: How does the extension work, how is it installed? Look inside the extension package (a zip file) and look for malicious files (e.g. .exe, .msi etc)
Look for XPInstall API functions that are dangerous (e.g. executing code on install)
Look for suspicious files in the extension folder (e.g. softlinks to other directories)
Look inside install.rdf - some tags can hide extensions so they don't appear in the addon manager
Extensions can have the same description as other installed extensions, so two appear in addon manager
Does the extension try to trick the user into thinking it's verified?
Look for pointers outside the extension, or flags that expose the extension object or content to untrusted code (e.g. contentaccessible=yes or xpcnativewrappers=no)
Extensions can be merged into the firefox UI - e.g. top toolbar, bottom status bar. They can also modify existing buttons e.g. Reload, Back, Forward or Home button.
Use the extension. Check the DOM of a test page with the extension loaded (they used mozreply to do this)
Debugging: can set breakpoints using Javascript debugger.
Sandbox: can be sidestepped by replacing code inside the sandbox or evaluating it from outside
XPCOM components: .dll or .so - compiled code that the extension may ship with, or may use existing components on the machine. May need to review source code or decompile. A bunch of components to watch out for.
wrappedJSObject: removes the protection of the XPComComponent, so they are avoiding the firefox protection.
Watch out for callback functions, which may be replaced / modified
window.OpenDialog: Opens any URI with elevated chrome privileges
Auth: Some expose credentials in plain text, e.g. GET or basic auth
Auth: Some expose functionality via javascript that can side-step normal process
Skype extension - a javascript call that any web page can use to start dialing your skype to any
XSS: Watch out for XSS issues - can execute in the chrome zone from DOM events, embedded XSS, recursive iframes
XSS: Extensions loading external scripts

They have applied their methodology to different extensions, and some responses have been slow or non-existent!

Here are some extensions that were demoed and had problems. They are all common or Mozilla recommended (all these have been fixed):

FireFTP: Could include malicious code in the welcome method of an FTP server, and the browser would execute it. Showed a proof of concept sending the contents of win.ini to a different server, and using BeEf to control client.
CoolPreviews: Susceptible to XSS if a data:// URI is used. Showed a remote code execution when right-clicking on a link and previewing it with CoolPreviews.
WizzRSS: HTML and Javascript in the <description> tag of RSS feeds is executed in the chrome zone. Showed a reverse shell onto the Windows machine from a malicious users machine.

Extension developers and vendors haven't got a security disclosure process yet - they don't know how to deal with the issues yet. Some extensions don't even publish an email address for the author.

Tools:

Firebug
MozRepl
BeEf - command console for an attacker to run script on the client computer.

OWASP NZ: Testing Web Services: Nick van Dadelszen, Lateral Security

Kirk Jackson — Sun, 12 Jul 2009 23:47:27 GMT

With shift to web services, where we are relying on client to secure stuff, we have to remember not to trust the client.

Gave a methodology for testing web services:

Service discovery:

Look for WSDL or similar files that contain service info, using search engines, site spidering or looking at app behaviour

Method discovery:

Look inside the WSDL to see what methods are available, or if there isn't one, you can brute force the webservice with common method names to find ones that exist.

OWASP top 10. These still all apply to web service calls, including:

Malicious file execution, insecure direct object reference,
CSRF with AJAX clients
Information leakage
Broken auth and session mgmt
Insecure crypto storage
Insecure communications - SSL is important
Failure to restrict URL access - protect admin etc web services from anonymous access

Web service specific tests:

XML issues (external entities, malformed XML, recursive XML, XML entity expansion, XML attribute blowup, overlarge XML and CDATA injection)

Can find out details inside the secure network, and CSRF etc machines in there.

WS-Routing issues

WS-Security is not a panacea - secures the method integrity and confidentiality, but doesn't stop bad stuff coming through.

Tools shown:

SIFT web method search tool - brute force the web service to find out which methods are supported.
Foundstone WS Digger - automate attacks against web services (XSS, SQL, Xpath etc)
Webscarab - to modify XML posted to web services and try connecting to external entities

OWASP NZ: Vulnerabilities in Action: Brett Moore, Insomnia Security

Kirk Jackson — Sun, 12 Jul 2009 22:37:46 GMT

If you don't own the 3 OWASP books, you've failed.

We're still facing the same vulnerabilities we already have, because we are doing something wrong. Maybe it's security professionals that are doing something wrong, by not educating developers properly.

Big security companies still having problems with their websites.

Most vulnerabilities are well known.

Security people don't write code. developers do. They don't "get" security:

Don't fix the root cause
Don't understand the threat
Most have never seen a vulnerability exploited

Sitting down with developers and stepping them through a vulnerability helps show them the light and they understand and think about vulnerabilities.

Talk today designed to show developers exploits in action.

Tools showed:

Burp - proxy tool for intercepting requests
A custom sitemap tool that Insomnia uses
An MS-SQL Enumeration tool that takes a vulnerable url and pulls out all the DB info using the master db to enumerate tables
ASPX Spy - if you can get this ASP.NET file up on to a server and run, it provides a UI for playing around with the OS.
SQL Map - an automatic SQL injection tool - can enumerate the DB, even if the data is not displayed by inferring the state of the db based on the page output.

Problems shown:

Robots.txt is not a place to list parts of your site that you don't want people to know about :)
Buying -1 quantity of a $1000 book leads to the users credit on the shopping site increasing by $1000 :)
XML parsing vulnerability that allows external entities to be referenced in the XML provided to a web service - which can pull the contents of a file off the server.
Query string parameters passed to the command interpreter, and used for file names.
PHP include let's you include PHP source from another web server (looks like you need to disable URL fopen wrappers).
Only securing GET requests to an admin directory.
Showed a fake version of the CCIP website with multiple problems.
Admin interface for a website is exposed to the internet.

Open questions:

Who owns server configuration? Architects, developers, system administrators? If server or framework config changes, then we're insecure.
Is it security professionals job to make sure problems are corrected?

OWASP NZ: Insecurity and the Internet: Paul Craig – Security-Assessment.com

Kirk Jackson — Sun, 12 Jul 2009 21:44:40 GMT

Paul raised the question: "Is internet security getting better or worse?"

By 2004 we had bought lots of security products, and now only port 80 is the only open port (default DENY). Hackers started hacking web apps instead.

Classic ASP was easy to hack. until in 2005 when vendors started releasing safer technology frameworks (2005? We were using it in 2002)

Note: ASP.NET doesn't have XSS protection built in, unless you leave ValidateRequest on (which no-one does), as controls only sporadically escape their output.

Paul looked at Security-Assessment's old pen-test projects and compared their vulnerabilities to those run recently.

"In 2003-2005, web application developers were F$%^&* bad"

"Developers fail at anything to do with files"

But the situations hasn't got much better lately. Admin sections are still accessible, SQL injection still found, but less common, file uploads allowing directory traversal.

When developers use framework security controls, they're okay. If they use custom security code, they mess it up.

"Less vulnerabilities in 2009 resulted in a shell"

"Security only works flawlessly when it's already implemented in the framework" - when developers build their own code, they normally mess it up.

Summary: The internet is getting more secure, but we're not there yet! Only need one bug to get in to a system.

Web Security – Napier

Kirk Jackson — Thu, 28 May 2009 10:56:37 GMT

I visited Napier at lunchtime today to present at the Hawkes Bay .NET User Group.

The presentation was a mixture of my earlier web security talk and the talk I gave recently on the Anti-XSS library which helps when you need to encode untrusted data.

Download File - Presentation

The Microsoft Anti-XSS Library (use instead of HttpUtility.Encode)
Security Runtime Engine - automatically encode ASP.NET control properties
The Classifieds web site starter kit
Which ASP.NET Controls Automatically Encode?
Clickjacking video
Framebusting:
http://pageofwords.com/blog/2008/10/06/FrameBustingInJavascript.aspx
OWASP - The Open Web Application Security Project - http://www.owasp.org

Subscribe to my blog: http://pageofwords.com

Cheers!

Kirk

Unsafe XmlDocument?

Kirk Jackson — Fri, 22 May 2009 08:54:43 GMT

When is it not safe to load an XML file into an XmlDocument object?

Any time the source is untrusted, it turns out:

Tom Hollander: Protecting against XML Entity Expansion attacks

That's one I haven't heard of before, and shows why every input from an untrusted source should be treated with care.

It reminds me of the zip expansion attacks that used to break mail servers 8 or so years ago:

Zip expansion attack. A large uniform file (for example 1 Gbyte of Zeros) is zipped and e-mail. AV or content filtering products attempt to unzip the attachment for checking, but are unable to do so because of lack of disc space. [ecommnet]

The old expanding file trick. What will they think of next?

Kirk

What is encoding? Cross site scripting and the AntiXSS encoding methods

Kirk Jackson — Wed, 25 Feb 2009 03:57:16 GMT

Encoding is "the process of transforming information from one format into another" [Wikipedia]

In the web development world, when we talk about encoding text, we are normally talking about taking some input text and making it appropriate to use in a given context. For example, taking the user's first name and last name, and making it safe to put in a tag within an html page.

We care about encoding most when we take input that we don't trust from our users - if we ever display that input we have to be careful to remove any characters that may interfere with the display of our web pages, cause javascript to run, or allow other malicious actions.

This article will help you understand what encoding is, why you need to do it and how that helps prevent cross-site scripting, and give a little introduction to the AntiXSS library.

A bold example

As a running example, let's say we are letting the user enter anything they want for their name - in an input box like this on our website:

We then take the text they enter and store it in our database. Later on when we display it on the web page, we wrap the text in bold tags so that it stands out:

In ASP.NET one way of doing this would be to put an ASP.NET label between tags:

Welcome to the website, <b><asp:Label ID="NameLabel" runat="server"></asp:Label></b>!

...and then in the code behind, take the name from our database and assign it to the Text property:

User user = GetFromDatabase();
NameLabel.Text = user.Name;

Trust no-one

The problem is, we've received this name directly from your user (who of course, you shouldn't trust), and we've stored it in a column in our database (which we now can't trust), and now we can't safely display it on our website without sanitising it or making it trust-worthy.

The number one lesson I try to give in my presentations on web security is "Don't trust...". You can't trust your user, you can't trust your employees, your students, or even your mother. There is no such thing as "safe input" that you receive over the Internet, everything you receive is suspect.

(Even people who are otherwise trustworthy might not be in control of their faculties if they have spyware or are virus-infected)

Everything is fine if the user enters only ascii characters:

But what happens if the user enters some html into the input box?

The user is now able to change how our page looks! Indeed, they can inject HTML, script or other content directly into pages on our website!

This is known as Cross-site scripting, or XSS, and is the bane of our existence as web developers.

What went wrong?

The ASP.NET label outputs the Text directly into the HTML output of the page:

<p> Welcome
to the website, <b><span id="NameLabel">Kirk </b><i>Jackson</i></span></b>! </p>

The problem here is that the ASP.NET label is not encoding the text before outputting it. The text is not appropriate to use in an HTML context, as it contains characters that have meaning in HTML (namely the characters making the and tags).

To make the user's name safe to use in an HTML context, we need to encode the inappropriate text to be safe in an HTML context:

Kirk &lt;/b>&lt;i>Jackson&lt;/i>

HTML Encoding

HTML encoding is turning a string into a safe block of text for insertion in an HTML web page.

This means it should not use any of the special characters that are used to mark the beginning or end of tags (< and >), attribute values (") or the ampersand character on it's own (&). If those characters are left in the string, then they could be used to start or stop HTML tags and change the behaviour of our page.

To remove these characters, HTML encoding requires them to be turned into character entity references, or numeric entity references. This stops them from being treated as special characters for formatting an HTML page, and just treats them as a character to be displayed.

Original character Character Entity Reference Numeric Entity Reference

< (less-than sign) < <

> (greater-than sign) > >

" (double quote) " "

& (ampersand) & &

The above table shows a few examples of how to encode special characters. For a more complete reference, see Wikipedia or W3C.

Note that since the ampersand character is used to start an encoded character sequence, it can't be used on it's own as a regular character. This is why ampersands should be encoded as & in HTML.

Original character	Character Entity Reference	Numeric Entity Reference
< (less-than sign)	<	<
> (greater-than sign)	>	>
" (double quote)	"	"
& (ampersand)	&	&

Once the users name is encoded, it will then be in the HTML as instead of , which means that in the above example, italic mode won't turn on:

The screenshot above looks a little weird, but the page now displays the text exactly as the user typed it in, without treating the users input as special HTML markup.

Attribute Encoding

Attribute encoding is turning a string into a safe block of text for use within an attribute of an HTML tag.

Attributes are the name/value pairs on a tag node in HTML (or SGML and XML, for that matter). For example, in the following HTML, the a tag has a title attribute:

<a href="foo.html" title="test">thing</a>

The text inside the title attribute is used to create a tool tip when the mouse pointer hovers over the hyperlink.

This HTML contains an a tag (an anchor tag), which has two attributes set: href and title. The a tag also contains some HTML within it: the text 'thing'. The contained text must be HTML encoded if you only want text within the a tag, and the two attributes must be attribute encoded.

At a simplistic level, text is valid inside an attribute as long as it doesn't contain double quotes ("), ampersands (&) or less-than symbols (<), as the double quote would prematurely end the attribute, and the other two characters must be encoded anywhere they are used within an HTML document (except when creating tags).

To extend our earlier example, imagine the users name is used as the tooltip of a link, to pop up before they follow the link. If we naively output the users name as a title attribute without encoding it, the user could inject some additional behaviour into our page. e.g.

<a href="foo.html" title="<%=
User.Name %>">thing</a>

If the user enters something malicious, for example by entering a double-quote followed by some javascript, then they have managed to inject extra HTML or javascript behaviour into our site:

The hover for the hyperlink looks okay, but when the user clicks the link, malicious javacript can run:

This is because the HTML that we have sent to the clients browser actually contains an onclick attribute that we didn't intend:

<a href="foo.html" title="Kirk" onclick="alert('Hi')">thing</a>

Encoding the users data before sending it to the browser would have protected us from this, and then the HTML sent would look like this:

<a href="foo.html" title="Kirk&quot;
onclick=&quot;alert('Hi')">thing</a>

Which correctly displays exactly what the user entered:

URL Encoding

URL encoding is turning a string into a safe block of text for appending on the query string of a URL.

The original specification for HTTP URL's (RFC 1738) specifies that URLs should only include certain characters, and all others must be encoded. This is similar to the case of HTML encoding, but there is a much smaller set of characters allowed, and the way you encode them is different.

To encode characters to append to a URL, you use a percentage symbol, followed by the two-digit hex number representing that character. For example:

Original character Character Entity Reference

space %20

/ (forward slash) %2F

" (double quote) %22

? (question mark) %3F

The above table shows a few examples of how to URL encode special characters. For a more complete reference, see Brian Wilson's URL Encoding page.

Original character	Character Entity Reference
space	%20
/ (forward slash)	%2F
" (double quote)	%22
? (question mark)	%3F

We need to encode strings before appending them to a URL, to make sure that untrusted input is not able to change the URL.

For example, if our page above constructed a URL to search Google for the name of the user entered into the website, it could look like this:

When the user clicks the link, they will search Google for their name.

Here the naive code is just constructing a url by joining the two strings together:

User user = GetFromDatabase(); string url
= "http://www.google.com/search?q=" +
user.Name;

But if a name with spaces is entered, then we're generating an invalid URL:

The URL is invalid because it contains an illegal character - a space that should be encoded as %20.

We could also be opening our users up to cross-site scripting bugs, because we are effectively letting them create any url they want. For example:

Here we are appending the ampersand (&) that the user entered directly to the end of the url, so rather than their text being passed to the server as the "q" parameter, we're letting them add other query string parameters (in this case, the "I'm feeling lucky!" button). The solution in this case is to encode the ampersand as %26.

The AntiXSS library

The AntiXSS library (currently at version 3.0 beta) has been built by the ~~Microsoft ACE Security and Performance Team~~ [ooops! By the Connected Information Security Group, sorry!]

The library provides two related functions:

Encoding methods to make text safe for a variety of contexts
An HttpHandler to automatically encode your ASP.NET controls

I'll cover the Security Runtime Engine HttpHandler in another post.

The encoding methods have been built using more robust and secure coding practices than the existing methods in the HttpUtility class of the .NET framework, so you should use them in preference when encoding your data.

public class AntiXss
{
    public static string HtmlAttributeEncode(string input);
    public static string HtmlEncode(string input);
    public static string JavaScriptEncode(string input);
    public static string UrlEncode(string input);
    public static string VisualBasicScriptEncode(string input);
    public static string XmlAttributeEncode(string input);
    public static string XmlEncode(string input);
}

You need to decide which context you're outputting text, and then choose the appropriate method to encode the text.

HtmlEncode - use for all HTML output, except for when you're adding text inside an attribute of a tag (e.g. use for ...)
HtmlAttributeEncode - use for text that will appear inside attributes of tags (e.g. <a title="...">)
UrlEncode - use for text that you are appending as a value in a url query string (e.g. http://google.com/search?q=...)
JavascriptEncode - use when you want to put the string into a javascript variable (e.g. var foo = '...'). This method will also create the surrounding quotes.
VisualBasicScriptEncode - use if you're unlucky enough to be creating pages with VBScript on them
XmlEncode, XmlAttributeEncode - the XML equivalents of the above HTML methods

To use inline in your ASPX page, you can call the library methods directly:

<a href="foo.html" title="<%=
HttpUtility.HtmlAttributeEncode(User.Name) %>">thing</a>

To use from your code-behind, decide whether your control outputs it's content as an attribute or in an html context, and then call the appropriate method:

Label1.Text = AntiXss.HtmlEncode(User.Name);

Deciding which context you're in and which encoding method to use is a major annoyance, so be sure to look at the Security Runtime Engine which does it for you. I'll write more about that in a future blog post, so please subscribe to my RSS.

Hopefully this article has helped you understand what encoding is; why you need to encode untrusted input and how that helps prevent cross-site scripting; and has given a little intro to the AntiXSS library.

Kirk

XSS Cheat Sheet and AntiXSS links

Kirk Jackson — Wed, 18 Feb 2009 09:20:27 GMT

I'll post the slides from my AntiXSS talk later, once I've cleaned them up. In the meantime, here's a couple of links:

AntiXSS library (including the Security Runtime Engine)
MarkAntiXSSOutput flag for the SRE
XSS (Cross Site Scripting) Cheat Sheet - here's some examples of places you can inject script into HTML to get around filters that people write
List of ASP.NET controls that need encoding

I will post the slides later.

Kirk

Twitter "don't click" clickjacking

Kirk Jackson — Thu, 12 Feb 2009 21:02:39 GMT

The twitter "don't click" messages are spreading like wildfire. It's a relatively benign form of clickjacking (analysis here) that tricks you into click a button when actually you're click on a hidden button on the twitter site that posts a tweet.

I've talked about clickjacking in Wellington, Auckland, Christchurch and Nelson, and while I don't know of a fool-proof way to protect yourself against click-jacking, you should do what twitter have done (and what I suggested at those talks) and include some frame-busting javascript at the top of every page in your site. Details are here: Framebusting in Javascript

Frame-busting works by unwrapping your site from being hosted inside an iframe. It won't stop all click-jacking attacks, and it won't protect all users, but like many security mitigations it's about layering several 90% solutions on top of each other to protect your users and your websites.

Kirk

Nelson, Wellington and cross site scripting

Kirk Jackson — Thu, 12 Feb 2009 10:09:55 GMT

It was a nice sunny day in Nelson yesterday, and it was nice to have a little look at the scenery afterwards (thanks, Daniel!).

I presented a similar "Overcoming your web insecurity" talk that I gave in Auckland recently [slides], and it was good fun diving in to some depth in the extra time we had... hopefully I managed to scare some people!

Next Wednesday at the Wellington .NET Users Group, Owen Evans (who also works at Xero) and I will be presenting two sessions.

Owen will be doing a LINQ Refresher to get us up to speed with the LINQ syntax for selecting, grouping, where-ing and more.

I will be talking about the Anti-XSS library, which is now in beta. The library is pretty cool and helps a lot with encoding data before it ends up on your website :)

More details of the event are here: LINQ Refresher, Anti-XSS and SDE Libraries

Hope to see you on Wednesday!

Kirk

Nelson this Wednesday: Overcoming your web insecurity

Kirk Jackson — Thu, 05 Feb 2009 21:17:38 GMT

I've got the afternoon off work this Wednesday 11 Feb, and am popping over to Nelson to present on web security (details below).

I hope to see you there!

Kirk

Daniel Ballinger wrote:
> Hi All,
>
> Kirk Jackson from the Wellington .NET user group will be in town on
> Wednesday the 11th of February and is giving a presentation.
>
> Title:
> Overcoming your web insecurity
>
> Abstract:

> As an ASP.NET developer, there are many things to think about while
> developing your web application. Come along to understand the
> fundamentals of developing a secure web application, and learn how to
> protect your site against the dangers of cross-site scripting, cross
> domain request forging and click-jacking.
>
> This session will be suitable for all levels of experience, and
> developers who use other web development platforms such as PHP or Java.
>

> Presenter:
> Kirk Jackson
>
> Useful links:
> http://pageofwords.com - Kirk's blog
>
> http://mscommunities.net.nz/ - The home of Microsoft communities in New Zealand
>
> When:
> Wednesday 11th February 2009
> Gather at 2:50 pm, starting at 3:00 pm.
>
> Approximately 1 hour 15 minutes plus pizza afterward.
>
> Where:
> FuseIT Ltd,
> Ground Floor,
> 7 Forests Rd,
> Stoke,
> Nelson
>
> (Off Nayland Rd and behind Carters)
> http://local.live.com/default.aspx?v=2&cp=-41.299774~173.236231&style=r&lvl=16&alt=-1000
> or
> http://maps.google.com/?ie=UTF8&om=1&z=17&ll=-41.299774,173.236231&spn=0.005239,0.010042&t=h
>
> If you are parking on site, please use the parks marked FuseIT that
> are at the back of the site.
>
> Giveaways:
> A single copy Microsoft Office 2007 Professional
>
> Catering: Pizza & Drinks
>
> Door Charge: Free
>
>
> RSVP to me if you are going to attend so I can guesstimate the food
> and drink requirements.
>
> However, feel free to turn up on the day though if you can't commit at
> the moment.
>
> Please feel free to invite anyone who may be interested in attending.
>
>
> Cheers,
> Daniel
>
> Daniel Ballinger
> Developer
> FuseIT ™

http://www.fishofprey.com/

The Seven Best Capers of 2008

Kirk Jackson — Wed, 07 Jan 2009 00:29:28 GMT

Wired's Threat Level blog compiles their list of the top 7 technology-aided crimes of 2008: The Seven Best Capers of 2008

The list is quite a humorous read.

Some of the crimes are caused by the silliness of the affected business, so it almost seems mean to prosecute the criminal :)

Ellerslie User Group - Overcoming your web insecurity

Kirk Jackson — Wed, 17 Dec 2008 10:19:01 GMT

That trip turned out to be a bit of a whirlwind. Sorry I had to dash straight after the presentation!

The talk was an introduction to cross-site scripting (XSS), cross domain request forgery (CDRF) and clickjacking, and used a common theme of "never trust users" to show how trusting GET, POST, Cookies, Headers or other user supplied data could be your downfall.

I've already posted the slides to this talk from back when I presented at the Christchurch Code Camp: Overcoming your web insecurity

Subscribe to my blog: http://pageofwords.com
The Classifieds web site starter kit
The Microsoft Anti-XSS Library (use instead of HttpUtility.Encode)
Which ASP.NET Controls Automatically Encode?
Clickjacking video
Framebusting:
http://pageofwords.com/blog/2008/10/06/FrameBustingInJavascript.aspx
Security Runtime Engine (coming, will help with ASP.NET controls)
OWASP – The Open Web Application Security Project – http://www.owasp.org

There's a new beta of the Anti-XSS library that you should check out when encoding your user-supplied data for use in HTML or attributes. At the same link is the new CAT.NET tool that analyses your code for weaknesses.

The Anti-XSS library now includes the Security Runtime Engine, which will help when encoding ASP.NET controls. I'll be posting about it here soon, so subscribe to my RSS feed :)

Google Browser Security Handbook

Kirk Jackson — Thu, 11 Dec 2008 11:39:15 GMT

This is very illuminating reading: Browser Security Handbook

The set of web pages cover the standard concepts within web browsers such as how they treat urls, javascript and css, and then covers security features within each browser, such as same-origin policies.

This is the first time I have seen information about all the browsers in one place, and should be a useful resource to both understand the browser protection mechanisms, and how browsers differ in their implementation of security controls.

Baking security in

Kirk Jackson — Mon, 24 Nov 2008 07:46:04 GMT

The Security Development Lifecycle website has been updated, and they have launched a cartoon:

http://www.bakingsecurityin.com/

You can follow the adventures of Kevin and how he transforms into Kevlarr (presumably while learning to write secure code).

They've got an RSS feed for the comics: RSS (although strip 2 didn't work in the RSS for me, so you might want to go to the site)

Christchurch Code Camp: Overcoming your web insecurity

Kirk Jackson — Sat, 01 Nov 2008 19:55:50 GMT

I had a fun time presenting my talk at the Christchurch Code Camp yesterday. I only fell off the stage once!

A collection of urls:

Subscribe to my blog: http://pageofwords.com
The Classifieds web site starter kit
The Microsoft Anti-XSS Library (use instead of HttpUtility.Encode)
Which ASP.NET Controls Automatically Encode?
Clickjacking video
Framebusting:
http://pageofwords.com/blog/2008/10/06/FrameBustingInJavascript.aspx
Security Runtime Engine (coming, will help with ASP.NET controls)
OWASP – The Open Web Application Security Project – http://www.owasp.org

Here's the sanitised version of my slides:

KirkJackson-CodeCampChchNov2008-Clean.pptx

Wellington conferences - Kiwicon and barcamp

Kirk Jackson — Mon, 27 Aug 2007 09:41:46 GMT

It's grassroots conference time in Wellington, with barcamp 2007 e-government on Sat 15 Sept, and Kiwicon on the Sat 17 and Sun 18 November.

Kiwicon is a security conference, and it sounds like it will be for the technically minded folks in the security community -- sessions on hacking, wifi insecurity, forensics and more. Sounds interesting!

barcamp is an un-conference about e-government / Government 2.0. Sessions are scheduled and time-slotted on the day. It looks like there's going to be some interesting stuff discussed - identity, privacy, community, accessibility and more.

Sounds like a few scheduled weekends away from the family...

Reverse engineering techniques to find security bugs: A case study of the ANI exploit

Kirk Jackson — Mon, 11 Jun 2007 09:34:29 GMT

I watched this video last night: Reverse engineering techniques to find security bugs: A case study of the ANI exploit

http://video.google.com/videoplay?docid=-7185841369679533904

From the blurb:

Alex Sotirov is a vulnerability engineer at determina. He will discuss some latest techniques in reverse engineering software to find vulnerabilities. Particularly, he'll discuss his technique that lead him to find the ANI bug (a critical new bug in WinXP and Vista).

Alex will describe the tools he uses for reverse engineering and show how he reverse engineered ANI Bug. He will continue to discussed Windows security mechanisms (ASLR, /GS) and describe how ANI exploit bypasses them.

Alex is one of the good guys. He works at determina on their intrusion prevention system, his job is to create exploits so that they can test if their software can detect and catch them. He often creates exploits by looking at the patches Microsoft releases to find out what bugs they fix.

In the presentation, Alex shows how to use a disassembly tool to analyse the differences between two dlls -- the original and the patched ones. He also explains some of the exploit-protection mechanisms, and how exploit authors can get around them:

/GS compiler switch which inserts a trap to check if the return pointer has been overridden (only works for functions with arrays in them, as an optimisation)
Data Execution Protection (DEP), which is a CPU feature to disable execution of code within data segments of memory. Stack overflows write into data blocks, and are thwarted when trying to jump to those blocks. It's only opt-in on desktop Windows, even on Vista (due to compat reasons).
Address space layout randomization (ASLR) which re-arranges the executable in memory so that jump locations are hard to pre-determine (but there are only 256 possible places, so it's still possible to guess the location).

Hints on how to design secure software:

Pick a good language and platform (e.g. Java, Python and I assume .NET). This avoids common pitfalls in languages like C++ and PHP.
Design your app to isolate components along trust boundaries. Develop a formal specification that details how areas of code that are accessed by users of different privilege interact with each other.

Things to avoid:

ActiveX. Always avoid.
Google Desktop Search web integration. [Must've been a popular bullet point in the room!] Exposes all local desktop search data to the possibility of a cross domain vulnerability in a browser. Securing the product relies on a browser being secure -- not a good idea.
Really hard to add security to an existing codebase (e.g. Windows, Oracle DB)

Take outs:

Assume software has security bugs. Build in things that will make exploitation harder, and will minimise damage.
Avoid single sign-on for web services, as if one app is exploited, other services can be attacked.

Alex ended with a diagram showing the exploit prevention features in different OS's:

OSX doesn't use many of the current protection techniques that other OS's currently do. I guess this shows how Microsoft are trying harder with each release, but Apple are finding it hard.

Security & Phone Phishing

Kirk Jackson — Sat, 09 Jun 2007 00:32:06 GMT

Two of my favourite areas of software development are privacy and security. As applications get less siloed and more connected, understanding the boundaries between "mine and theirs", and implementing the system correctly are becoming increasingly important.

A little tid-bit I found interesting today was:

Did you know that the new trend is phone phishing? Criminals use VoIP to emulate the bank’s voice prompt system and lure people into giving their account information.
(http://frenchfamily.org/hunter/?p=132)

That's worth thinking about if you're an organisation that provides a phone-based service such as phone banking or checking account balances. Tricking someone to dial a phone number (especially an 0800) is probably as easy as tricking them into going to the wrong website.