securing web application adding the lock to the gate l.
Skip this Video
Download Presentation
Securing Web Application Adding the lock to the gate

Loading in 2 Seconds...

play fullscreen
1 / 48

Securing Web Application Adding the lock to the gate - PowerPoint PPT Presentation

  • Uploaded on

Securing Web Application Adding the lock to the gate. Jairam Ramesh Security Research Consultant | Microsoft Corporation Agenda. Internet Attacks IIS 7 and comparison with its predecessors Counteracting the various attacks!. Securing the Internet.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Securing Web Application Adding the lock to the gate' - leann

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
securing web application adding the lock to the gate

Securing Web ApplicationAdding the lock to the gate

Jairam Ramesh

Security Research Consultant | Microsoft Corporation

  • Internet Attacks
  • IIS 7 and comparison with its predecessors
  • Counteracting the various attacks!
common types of attacks
Common Types of Attacks

Configuration management

Unauthorized access to administration interfaces

Unauthorized access to configuration stores

Retrieval of plain text configuration secrets

Lack of individual Accountability

Over-privileged process and service accounts

Sensitive Data

Network Eavesdropping

  • Buffer Overflow
  • Cross-site scripting
  • SQL Injection
  • Canonicalization
  • Authentication
  • Brute force attacks
  • Dictionary attacks
  • Cookie replay attacks
  • Credentials theft
  • Authorization
  • Disclosure of confidential data
common types of attacks5
Common Types of Attacks

Denial of Service

Session Hijacking

Parameter Manipulation

Query String manipulation

Form field manipulation

HTTP Header manipulation

  • Data tampering
  • Luring Attacks
  • Session Replay
  • Man in the middle attacks
  • Cryptography
  • Weak Encryption
the basic foundation
The basic foundation
  • Scalability
  • Security
  • Trust

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








4/15Server2003 RTM

(WebDA / DoS)





















< Critical

  • 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


iis 7 security features
IIS 7 Security Features
  • Modular Design:
    • Reduced exposure at installation and runtime
  • .NET Integration:
    • Forms Authorization for any content
    • Use of .NET Role and Membership Providers
  • Built in anonymous account
    • Easier to administer, restore, and configure
  • Application Pool Isolation
    • Improved Sandboxing between applications
  • URLAuthorization and Request Filtering
    • New choices for improving security
  • Kernel mode SSL and authentication
    • Faster negotiation of security exchanges, fewer problems
reduced footprints
Reduced Footprints
  • Features 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
.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 SAM
    • SQL 2005 Express for static site users
    • ADAM for users and groups in a PHP application
    • DB2 mainframe users and groups in
url authorization
URL Authorization
  • Control access to sites, folders, or files without using NTFS
  • Inspired by 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
request filtering
Request Filtering
  • Most of the functions in URLScan and more have been integrated in v7
  • Very strong security feature like
    • Preventing URLs that contain “any string”
    • Blocking URLs over “X” in length
    • Preventing delivery of “.config” or “/bin”
  • Easy to read rules stored in .config
    • Delegate control to store in web.config
    • Filtering rules are then portable
  • Cannot be edited in UI
  • New error codes track rejections
  • User Encryption to protect Passwords, etc.
changes in anonymous users
Changes in Anonymous Users
  • IUSR instead of IUSR_<servername>
  • IUSR is “built in”, not a local account
    • Cannot logon to system with this account
    • No password to worry about
    • Same SID on all Vista/LH servers
    • File ACLS are valid between servers
  • Allow anonymous access & turn off IUSR:
    • Use process identity for anon access when enabled
    • Disabled by default
security features moved to kernel
Security Features moved to Kernel
  • Kernel Mode SSL
    • Improves performance
    • Reduces context switch to user mode
  • Kernel Mode Authentication
    • Improves performance
    • Kerberos functions when using custom application pool identity!
    • No need to use SETSPN as access to DC occurs as machine account
encypting keys in web config
Encypting keys in web.config
  • Passwords may be present in .config
    • No secrets by default
  • Passwords are needed for:
    • UNC paths
    • Shared Configuration
  • Custom Anon or App Pool identity
  • Passwords are encrypted when added
    • AES provider is the default
  • Encryption provider can be customized
security checklist
Security Checklist

General Assumptions

  • 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.
security checklist26
Security Checklist

Design Guidelines

  • 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 properly
  • Be careful when using the Add/Remove control panel on an IIS Server.
security checklist27
Security Checklist

Installation Configuration

  • 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)
security checklist28
Security Checklist

Installation Configuration

  • 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.
security checklist29
Security Checklist

Installation Configuration

  • 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.
security checklist30
Security Checklist

Installation Configuration

  • 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.
security checklist31
Security Checklist

Authentication Mode

  • 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.
security checklist32
Security Checklist

Authorization Changes

  • 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/Execute
  • Restrict 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\”

Buffer Overflow

  • Perform thorough input validation
  • Wherever possible, limit application's use of unmanaged code
  • If unmanaged API is called in your application, check the values passed for the parameters of unmanaged API to avoid this attack
  • Compile 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.

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 input
  • User inputs should be encoded using HTMLEncode and URLEncode functions

SQL Injection

  • Validate the input received by the application using regular expression
  • Set appropriate privileges to execute the SQL commands
  • Stored procedures executed using arguments should be parameterized stored procedures

Network eavesdropping

  • Use Kerberos authentication or Windows authentication which doesn't transmit the password over the network
  • When 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

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.

Cookie replay attacks

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

Data tampering

  • Use tamper resistant protocols such as hashed message authentication codes.

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.

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

Man in the middle attacks

  • Use strong encryption.
  • Use Hashing.

Denial of Service

  • Each individual input received from the user should be thoroughly validated
  • Handle all types of exception in your application through out the code base
auditing logging
Auditing & Logging
  • Enable auditing and logging in web server, database server and application server.
  • Identify the key events and log them. For eg. Login, logout events
  • Avoid shared accounts. It will lead to difficulty as we cannot trace out the original source
  • All critical application level operations should be logged
  • Read the log files every day to detect suspicious activity. Always maintain the back up of log files
  • If 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
  • ASP.NET 2.0 Internet Security Reference Implementation
  • Official Microsoft IIS Site

feedback qna
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

Or email us at

  • Use the Question Manager on LiveMeeting to ask your questions now!
contact optional slide
Contact (optional slide)
  • Email Address