Securing Web ApplicationAdding the lock to the gate

Jairam RameshSecurity Research Consultant | Microsoft Corporationv-jairar@microsoft.com

Agenda

Internet Attacks

IIS 7 and comparison with its predecessors

Counteracting the various attacks!

Securing the Internet

Common Types of AttacksBuffer OverflowCross-site scriptingSQL InjectionCanonicalizationAuthenticationBrute force attacksDictionary attacksCookie replay attacksCredentials theftAuthorizationDisclosure of confidential data

Configuration managementUnauthorized access to administration interfacesUnauthorized access to configuration storesRetrieval of plain text configuration secretsLack of individual AccountabilityOver-privileged process and service accountsSensitive DataNetwork Eavesdropping

Common Types of AttacksData tamperingLuring AttacksSession ReplayMan in the middle attacksCryptographyWeak Encryption

Denial of ServiceSession HijackingParameter ManipulationQuery String manipulationForm field manipulationHTTP Header manipulation

What is safe then?

IIS 7 Security

The basic foundation

ScalabilitySecurityTrust

A solid foundation to build IIS 7 was already set by IIS 6

Notes •MS02-011 & 012 not included: updates SMTP service only

•ASP.NET adds: 1 – v 2.0 2 - v 1.1 3 - v 1.0

= Critical

= Rollup with X updates

X

IIS 6IIS 5

2002

2003

2004 2005

IIS 4

4/15Server2003 RTM

4/1002-018

6/1102-028

10/3002-062

5/2803-018

10/1204-021

(WebDA / DoS)

7/1304-0218

8

4

4

4

4

< Critical

200606/1106-034

(ASP)

http://secunia.com/advisories/product/1438/?task=statistics

IIS 7 Security FeaturesModular Design:

Reduced exposure at installation and runtime

.NET Integration:Forms Authorization for any contentUse of .NET Role and Membership Providers

Built in anonymous accountEasier to administer, restore, and configure

Application Pool IsolationImproved Sandboxing between applications

URLAuthorization and Request FilteringNew choices for improving security

Kernel mode SSL and authenticationFaster negotiation of security exchanges, fewer problems

Reduced FootprintsFeatures implemented as discrete modules

Modularity improves security

Reduced module set by default at install

Remove modules that you do not need

Extensibility allows security customization

Add authentication, logging, or blocking mechanisms

.net provided Security Features

Integrated pipeline enables Forms authentication with any content

Leverage existing user database with .NET Role/Membership providers

Examples: Store user names in:Active directory or local SAMSQL 2005 Express for static site usersADAM for users and groups in a PHP applicationDB2 mainframe users and groups in ASP.net

Introducing IIS 7 Features

DEMO

URL AuthorizationControl access to sites, folders, or files without using NTFS

Inspired by ASP.net URL authorization, but designed for administrators

Rules are stored in .config files

Delegate control to store in web.config

Authorization rules are then portable

Xcopy and maintain security

Use Windows principles or .NET provider

URL Authorization

DEMO

Request FilteringMost of the functions in URLScan and more have been integrated in v7

Very strong security feature likePreventing URLs that contain “any string”Blocking URLs over “X” in lengthPreventing delivery of “.config” or “/bin”

Easy to read rules stored in .configDelegate control to store in web.configFiltering rules are then portable

Cannot be edited in UI

New error codes track rejections

User Encryption to protect Passwords, etc.

Request Filtering Error Codes

Request Filtering

DEMO

Changes in Anonymous Users

IUSR instead of IUSR_<servername>

IUSR is “built in”, not a local accountCannot logon to system with this accountNo password to worry aboutSame SID on all Vista/LH serversFile ACLS are valid between servers

Allow anonymous access & turn off IUSR:Use process identity for anon access when enabledDisabled by default

Security Features moved to Kernel

Kernel Mode SSLImproves performance Reduces context switch to user mode

Kernel Mode AuthenticationImproves performanceKerberos functions when using custom application pool identity!No need to use SETSPN as access to DC occurs as machine account

Encypting keys in web.configPasswords may be present in .config

No secrets by default

Passwords are needed for:UNC pathsShared Configuration

Custom Anon or App Pool identity

Passwords are encrypted when addedAES provider is the default

Encryption provider can be customized

Encrypting the web.config

DEMO

Security Checklist

• No IIS on a domain controller

• Install only services needed (ftp, www, smtp, nntp).

• Virtual directories are NEVER used across servers.

• The underlying Windows OS has been secured.

• Only system administrators are local administrators.

General Assumptions

Security Checklist

• Websites should NEVER be on the system drive.• Setup SSL if transmitted information is sensitive. • All FTP sites, and as needed WWW sites should enable IP

filtering for Stanford-only sites. IPSec filters can be used to accomplish this.

• Virtual directories should be used as little as possible. \• Remove NTFS write perms everywhere possible.• Don’t make it easy to find your scripts and code.

Consider renaming the extension on all of your scripts to something uncommon.Consider compiling scripts into dll files.Web applications (i.e. scripts and executables) only need a limited amount of permissions to run properlyBe careful when using the Add/Remove control panel on an IIS Server.

Design Guidelines

Security Checklist

• Delete all default virtual directories (icon w/ world on top of folder) and application roots (icon w/ green ball in box)

• Delete iisadmin• Delete iissamples• Delete msadc.• Delete iishelp• Delete scripts• Delete printers• Delete ALL default content.• Delete %systemdirectory%\inetsrv\iisadmin• Delete %systemdirectory%\inetsrv\iisadmpwd• Delete inetpub\wwwroot (or \ftproot or \smtproot)

Installation Configuration

Security Checklist

Delete %systemdrive%\program files\common files\system\msadc.

Configure Default Website with extremely secure

Configure all website(s) with host header matching the DNS name of the site.

 Home directory IIS perms: Enable Read and Log. TURN OFF Write, Index, Browsing, Script Source Access (only WebDAV uses this), and Frontpage Web permissions. Set execute permissions to None. Enable execute permissions for the directory that holds your scripts.

Disable all unnecessary ISAPI filters. Do this under ISM, ISAPI filters tab.

Installation Configuration

Security Checklist

• Delete the Frontpage ISAPI filter (or extensions on older IIS servers), if you have a choice. If Frontpage ISAPI (extensions) is required, make them read only.

• Digest Authentication. This authentication method requires support for reversibly encrypted passwords—which is a bad idea

• HTTP Compression. This filter allows compression of the http stream.

• SSL. It’s unlikely you wouldn’t want SSL support, but if you don’t need it, then delete it.

Installation Configuration

Security Checklist

Delete the dll files associated with ISAPI filters that you disabled. FrontPage: fpexdll.dll, Digest: md5filt.dll, Compression: compfilt.dll, SSL: sspifilt.dll.

Unmap the following extensions (if possible):.asa, .asp, .bat, .cdx, .cer, .htr, .htw, .ida, .idc, .idq, .printer, .shtm, .shtml, .stm.

Within ISM, go to the Home Directory tab, and choose Configuration button.

Disable “Enable Parent Paths” setting. Go to ISM, Home Directory tab, Configuration button, App Options tab, uncheck checkbox.

Installation Configuration

Security Checklist

Basic authentication disabled at site level, virtual directory level, directory level –Everywhere!

Digest authentication disabled everywhere.

IUSR & IWAM accounts should not be domain users nor should they be guests. If no anonymous access is required, delete these accounts.

If web data is ultra-sensitive consider placing server outside a domain.

Authentication Mode

Security Checklist

Enable IIS auditing, change to W3 extended logging, and check that the info that is being logged is appropriate.Set permission to IIS logs to system and local administrators only.Remove write perms to hklm\software for non-admin accounts. Administrators & System: FULL, Everyone: Read/ExecuteRestrict NTFS perms to ALL executables on system. NTFS perms: Administrators & System: FULL, Users: Read/Execute. Give IUSR account execute permissions sparingly.Restrict perms to any script interpreters such as perl. NTFS perms: Administrators & System: FULL, Everyone: Read/Execute. Give IUSR account execute permissions sparingly.Ensure Everyone has only read on:“Web root”“%systemroot%” “%systemroot%\system32” “%systemroot%\system32\inetsrv” “%systemroot%\system32\inetsrv\asp” “%systemroot%\program files\common files\”

Authorization Changes

Counteracting

Buffer Overflow

Perform thorough input validationWherever possible, limit application's use of unmanaged codeIf unmanaged API is called in your application, check the values passed for the parameters of unmanaged API to avoid this attackCompile your code with /GS flag if it is developed in Microsoft Visual C++ system. The /GS option detects some buffer overruns, which overwrite the return address - a common technique for exploiting code that does not enforce buffer size restrictions. This is achieved by injecting security checks into the compiled code.

Counteracting

Cross-site scripting

Perform thorough input validation on form fields, query strings, cookies. Always check for scripting tags and filter the same. Regular expression is the best way of validating inputUser inputs should be encoded using HTMLEncode and URLEncode functions

Counteracting

SQL Injection

Validate the input received by the application using regular expressionSet appropriate privileges to execute the SQL commandsStored procedures executed using arguments should be parameterized stored procedures

CounteractingNetwork eavesdropping

Use Kerberos authentication or Windows authentication which doesn't transmit the password over the networkWhen there is a necessity for transmitting password through network, use an encryption communication channel like SSL which will encrypt the contents passed through network channel

Counteracting

Brute force attacks

Use strong passwords with that are complex. Use mixture of uppercase, lowercase, numerals, special characters in the password that makes difficult to crack.

Store non-reversible password hashes in the user store. Also combine a salt value with the password hash.

Counteracting

Cookie replay attacks

Use SSL that encrypts all the information including cookie information passed through the channelAlways use timeout property for the cookie information. This will reduce the probability of attack.

Counteracting

Data tampering

Use tamper resistant protocols such as hashed message authentication codes.

Counteracting

Session Hijacking

Avoid storing anything in the session objects.

Implement SSL as it will encrypt all the information that is transmitted via the network

Allow only one session per user at a time.

Incase if SSL is not implemented and still there is a need to store information in the session object, ensure you set a time period for expiry.

Counteracting

Session Replay

Do not store authentication information on the client

Whenever a critical function is being called or an operation is performed, re-authenticate the user

Set expiry date for all cookies

CounteractingMan in the middle attacks

Use strong encryption.

Use Hashing.

Counteracting

Denial of Service

Each individual input received from the user should be thoroughly validatedHandle all types of exception in your application through out the code base

Auditing & LoggingEnable auditing and logging in web server, database server and application server.Identify the key events and log them. For eg. Login, logout eventsAvoid shared accounts. It will lead to difficulty as we cannot trace out the original sourceAll critical application level operations should be loggedRead the log files every day to detect suspicious activity. Always maintain the back up of log filesIf the platform provides any support to log important transactions, make use of that.Do not keep the log files in the default location folder. Move it to a different location.Secure log files using Access Control Lists

References

ASP.NET 2.0 Internet Security Reference Implementation http://blogs.microsoft.co.il/files/folders/36103/download.aspx

Official Microsoft IIS Sitehttp://www.iis.net/

Feedback / QnA

Your Feedback is Important!Please take a few moments to fill out our

online feedback form at: << Feedback URL – Ask your organizer for this in advance>>

For detailed feedback, use the form at http://www.connectwithlife.co.in/vtd/helpdesk.aspx

Or email us at vtd@microsoft.com

Use the Question Manager on LiveMeeting to ask your questions now!

Contact (optional slide)

Email Addressv-jairar@microsoft.com

© 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.

The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after

the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.