Web Application Firewalls at SCSU: How and Why

1. Web Application Firewallsat SCSU: How and Why By Ben Pratt and Clint Forseth

2. Who is this guy? • Ben Pratt • Primary Role: Course Mgmt. Sys. Admin • Secondary Roles: Printer Server Admin, Web Application Firewall Admin, “Other Duties as Assigned” • Clint Forseth • Primary Role: Active Directory Accounts Admin • Secondary Roles: Web Server Admin, Database Admin, Applications Developer, DNS/DHCP Admin,“Jack of All Trades, …”

3. About St. Cloud State University • “Largest” University in MnSCU • Located in Central Minnesota • About 70 miles NW of Minneapolis • Enrollment: ~1600 students • Web Environment • Primarily Microsoft (Windows 2003/2008 and IIS) • Classic ASP Web Apps with some PHP, Java, etc. • Most new development in .NET

4. Common Web App Attacks • SQL Injection • Allows an attacker to run unwanted SQL queries against your database • Can result in data loss or data manipulation • SQL Inject Me (Firefox Add-on), sqlmap, etc. • http://xkcd.com/327/

5. Common Web App Attacks • Cross Site Scripting (XSS) • Allows an attacker to modify your web site • Can result in unwanted HTML or scripts being run as your web site • XSS Me (Firefox Add-on), XSS-Proxy, etc. • Many Others • Information gathering • Forceful browsing • Buffer overflow • Cookie tampering

6. Web Application Attack/Test Tools • Samurai Web Testing Framework (WTF) • http://samurai.inguardians.com/ • W3af • http://w3af.sourceforge.net/ • OWASP WebScarab • http://www.owasp.org/ • Others • http://www.cs.washington.edu/homes/mernst/pubs/create-attacks-tr054-abstract.html • http://www.google.com

7. What is a Web Application Firewall? • A System or Application that Limits Data Sent Between a Web Browser and a Web Server • Inspects traffic at layer 7 of the OSI Model • Runs Traffic Through Rules to Detect Attacks Against Web Applications • Rules can check for SQL Injection Attempts,Cross Site Scripting (XSS) Attempts, invalid cookies, manipulated form data, other invalid user submitted data

8. What Happened in April 2008? • http://isc.sans.org/diary.html?storyid=4393 • SQL Injection Worm on the Loose • “…a SQL Injection worm that is on the loose.  From a quick google [sic] search it shows that there are about 4,000 websites infected and that this worm started at least mid-April if not earlier. …but what they are doing is putting in some scripts and iframes to take over visitors to the websites.” • http://www.net-security.org/secworld.php?id=6124 • Winzipices.cn SQL injection attack • “According to Microsoft, there's no patch to fix the issue -- the vulnerability lies in custom ASP code that fails to follow well-established security practices for handling database input.”

9. Defending Against Web Attacks • Write More Secure Web Applications • Getting easier with more secure development tools • Requires rewrite/updating of old/insecure apps • Depends on trusting 3rd party applications • Depends on attacker methods not evolving • Use Web Application Firewall • Allows for separation of web application security responsibilities from development team • Can be implemented with almost anyweb application • Single/reduced points of updates for new attacks

10. Host Based Web App Firewall • dotDefender from AppliCure • ISAPI filter for IIS (Available for Apache too) • Installs Directly on Web Server • Quick to Install and Secure Web Sites • Requires Less Network Knowledge to Configure • Lower Cost for Individual Servers • Ability to Protect All SSL Traffic • Higher Impact on Server Performance • All Attacks Reach Web Server

11. Network Based Web App Firewall • Citrix NetScaler Application Firewall • Integrated into NetScaler Load Balancers • Positive Security Model (Default Deny) • Use of RegEx to minimize rules • Takes Application Firewall Processing Load Off of Web Servers • May Require Re-architecture of Datacenter Network and ACLs • May require code modification for applications • Higher Cost for Individual Servers

12. SCSU’s Web App Firewall History • Required Immediate Response to Active Web Application Attacks with Ability to Grow • dotDefender Installed for Quick Response to Common Web Application Attacks • Determined Long Term Response Would Utilize Citrix Network Load Balancers Already in Environment

13. Web App Firewall Timeline • Initial Focus on Public, Unauthenticated Sites • April 2008 • dotDefender installed with (mostly) default settings • June 2008 • Citrix Application Firewall training • July & August 2008 • Updated sites not routing traffic through theCitrix network load balancer (nlb) to do so • A majority of our public facing web sites were put into Learning Mode

14. Web App Firewall Timeline • September 2008 • The sites that had been in Learning Mode were switched into Blocking Mode • October 2008 • Most popular/open sites were felt to be secure • Ongoing • As new issues arise or applications come online the app firewall rules are adjusted • A plan is being developed for securing further, “tricky” applications • Dynamic URLs, applications reading IP headers, etc.

15. Other steps to improve web application security environment • Focusing on .NET Development for New Apps • Increased data input validation • Project Plans and Change Management • Project plans include security and privacy section • More Formalized Change Management Procedures • Increasing Developer Awareness of Common Web Application Attacks • Increased training and tools • Peer reviews of code

16. Other Reasons for a WAF • Payment Card Industry Data Security Standard (PCI-DSS) version 1.2 • Required as of June 30, 2008 • Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes • Installing a web-application firewall in front ofpublic-facing web applications • Forces someone other than your developers to understand the functionality of your site

17. Closing • Contact Info • Ben Pratt • bepratt@stcloudstate.edu • Evaluations • http://www.resnetsymposium.org/rspm/evaluation/ • Questions?