1 / 48

Securing Web Application Adding the lock to the gate

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

leann
Download Presentation

Securing Web Application Adding the lock to the gate

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Securing Web ApplicationAdding the lock to the gate Jairam Ramesh Security Research Consultant | Microsoft Corporation v-jairar@microsoft.com

  2. Agenda • Internet Attacks • IIS 7 and comparison with its predecessors • Counteracting the various attacks!

  3. Securing the Internet

  4. 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

  5. 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

  6. What is safe then?

  7. IIS 7 Security

  8. The basic foundation • Scalability • Security • Trust A solid foundation to build IIS 7 was already set by IIS 6

  9. (ASP) 2005 2006 2004 2002 2003 4/15Server2003 RTM (WebDA / DoS) 06/11 06-034 10/12 04-021 IIS6 4/1002-018 6/1102-028 10/30 02-062 5/2803-018 IIS 5 8 4 4 7/13 04-021 IIS 4 4 8 4 < 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 X

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

  11. 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

  12. 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

  13. .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 ASP.net

  14. DEMO Introducing IIS 7 Features

  15. URL Authorization • Control 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

  16. DEMO URL Authorization

  17. 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.

  18. Request Filtering Error Codes

  19. DEMO Request Filtering

  20. 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

  21. 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

  22. 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

  23. DEMO Encrypting the web.config

  24. 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.

  25. 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.

  26. 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)

  27. 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.

  28. 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.

  29. 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.

  30. 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.

  31. 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\”

  32. Counteracting 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.

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

  34. Counteracting 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

  35. Counteracting 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

  36. 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.

  37. Counteracting 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.

  38. Counteracting Data tampering • Use tamper resistant protocols such as hashed message authentication codes.

  39. 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.

  40. 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

  41. Counteracting Man in the middle attacks • Use strong encryption. • Use Hashing.

  42. Counteracting 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

  43. 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

  44. References • ASP.NET 2.0 Internet Security Reference Implementationhttp://blogs.microsoft.co.il/files/folders/36103/download.aspx • Official Microsoft IIS Site http://www.iis.net/

  45. 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!

  46. Contact (optional slide) • Email Address v-jairar@microsoft.com

More Related