web application security ect 582 robin burke. outline ssl web appliation flaws configuration...

Download Web Application Security ECT 582 Robin Burke. Outline SSL Web appliation flaws configuration application design implementation state management command

Post on 01-Jan-2016

213 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • Web Application SecurityECT 582Robin Burke

  • OutlineSSLWeb appliation flawsconfigurationapplication designimplementationstate managementcommand injectioncross-site scripting

  • Secure Sockets LayerSocket: The Berkeley Unix mechanism for creating a virtual connection between processes. Sockets interface Unix's standard I/O with its network communication facilities....The socket has associated with it a socket address, consisting of a port number and the local host's network address.-- FOLDOC

  • Network Layers

  • Session LayerNot normally part of the "big four"part of the original OSI 7-layer pictureA session layer establishes a connection between client and serverextends beyond individual TCP/IP connectionsnot part of any particular applicationPrecisely where web encryption should resideno need to change applicationcan be used over an extended interaction

  • SSL (now TLS)Establishes how a client and server can exchange encrypted contentGoalsCryptographic securityInteroperabilityExtensibilityRelative efficiency

  • Protocol phasesClientHellorequest to use SSL/TLShttps in browserincludes client-generated random numberServerHelloconfirmation that SSL/TLS is availableincludes server-generated random numberusually followed by server certificateClientKeyExchangeclient computes a secret key and encrypts itor client initiates Diffie-Helman key exchangethen both client and server compute a "master secret"

  • Protocol phases, cont'dMaster secret is key material for different purposesclient MAC secret, server MAC secret, client encryption key, server encryption key, client write IVserver write IV,Finishedserver and client exchange encrypted messagecontains a hash of all of the messages exchanged in the protocol so farfinal verification of "agreed to" parameters

  • Protocol phases, cont'dClient can request resumption of previously-negotiated interactionserver policies on time-out controlOptionsServer can request a client certificatetwo-way authenticationEither client or server can request that the cipher parameters be changedcan happen at any timerenegotiation

  • OverheadCommunication overheadboth sides exchange much more datacertificates, etc.Computational overheadcertificate verificationcryptographic operationsIn generalprotect only those communications where content must be protected

  • PKISSL/TLS assumes PKICertificate authenticates serverIn realityverification path limited to browser defaults

  • Web Application Security"Web application code is part of your security perimeter"Web application securityCannot be ignoredA regular site of attacks

  • Example #1: Updates75% of all web servers running MS IIS 5.0 are vulnerable to exploitation. Microsoft issued a security alert on March 17 2003 regarding a buffer overflow vulnerability which allows attackers to execute arbitrary code on Windows 2000 machines. Netcraft survey found 767,721 IPs running IIS 5.0 and offering WebDAV and 273,496 IPs running IIS 5.0 with the protocol turned off. -- Securitystats.com, http://www.securitystats.com/webdeface.asp:

  • Example #2: CGI attacks"CGI attacks are powerful, and the vulnerabilities are common. Sure it is possible to write secure CI scripts, but hardly anyone does. One company that auits Web sites for appliation-level bugs like this has never founc a Web site they could not hack. That's 100 percent vulnerabilities."-- Schneier, "Secrets and Lies"

  • Example #3: Session hijacking"In a survey of 45 Web applications in production at client companies, @stake researchers found that 31% of e-commerce applications examined were vulnerable to session replay or hijacking -- the highest incidence of Web application security defects encountered in the study. @stake's Andrew Jaquith (2002) comments, "user session security remains the Achilles heel of most e-business applications."-- Jeni Li "State Management in Web Applications"

  • The problemDesignlittle consideration of security in web's originsDiversity of platformsOS (Linux, UNIX, WIndows, Mac OS, ...)Servers (IIS, Apache, ...), Browsers (Netscape, Mozilla, Internet Explorer, Safari, Lynx, Opera, WebTV, ...) and custom scripts, Diversity of technologiesApplication frameworks (Perl, PHP, Python, Java, Javascript, C, tcl, ...), Standards (HTTP, HTML, XML, SSL, SQL, RSS, encryption, cookies, webcasts, ...),

  • Web development processWeb developers are (often) not programmersWeb developers (often) have no secure programming experienceWeb developers (often) are adapting cookie-cutter scripts from books or on-line librariesWeb development timeframes exclude security review

  • TechnologyBrowser compensationbrowser will correct "errors" on the pageinterpreting a ">" as a "
  • Configuration(OWASP 10)Web-accessible directories are public hunting groundsseparate executable code E from ordinary HTML Wconfigure server to execute (E) and display (W)Good practicedistinct directory tree for executable codeBad practiceusing file extensions to distinguish between regular files and executable ones.pl for Perl executables.pl.bak, .pl~ may still be viewableputting command interpreters in executable directorieshorrors!

  • Configuration, cont'dWeb-accessible directories are public hunting groundsStore sensitive information (passwords, session data) outside the web-accessible directory structureBad practicesometimes session id files show up in Google searches!scripts often hard-code username and password information for databases

  • Configuration cont'dThe web server process is the most likely point of compromiseCreate a separate user for the web server processcompromise of server gives control of that account, but not whole machineminimize the privileges of the "web server" userGood practicehave server configuration files readable but not writable by the "web server" userBad practicerun the server as root (administrator)

  • Configuration, cont'dSome web server capabilities are inherently dangerousEliminate capabilities that are not strictly neededdirectory listingssymbolic linksexecutable server-side includes

  • Configuration, cont'dUsers can create backdoors by enabling Internet servicesGood practiceuser educationachieving a balance between limiting risk and allowing individual initiativeBad practicecreating such draconian policies that users feel compelled to circumvent them to get things done

  • Application designInput to a web application can use either "GET" or "POST"GETfaster, but information is displayed as part of URL in browserPOSTinformation is part of request data, but not shownInformation in GET requests can leakprying eyesbrowser history"refer" headerCaching software may handle GET requests differentlyGood practiceUse POST for web applications

  • Application design, cont'd(OWASP A1)Input from the browser cannot be trusteddata passed to the browser may be alteredyour page may not be generating the requestGood practicewrite a specification for valid inputname field: [A-Za-z0-9] or . or or 'check against itBad practiceassuming that your Javascript validation code protects you

  • Example: Hidden variablesThis web page contains a form with a hidden valueThe application is passing the price as a hidden variable in the form. An attacker could easily save the form, edit it, and use the edited versionordering 100 widgets at 1 cent each

  • Hidden variables, cont'dEven easier the attackercan enter the parameters into the URLif the application doesn't test for GET vs POSThttp://josquin.cti.depaul.edu/cgi-bin/buyit.pl?price=0.1&order=10Not as silly as it soundsThis weakness was actually identified in 11 shopping applications surveyed in 2000.

  • ImplementationMany choicesPerl, Python, PHP, Java servlets, tcl, C, a command shell, ASP, JSPSome more secure than othersGoodPerl with "taint" modeJSPASPPythonRiskierCPHPDangerouscommand shell

  • State managementWeb protocols is statelessone connection like any otherE-commerce applications need stateuser loginsshopping cartsState maintenancehidden valuesproblematiccookies

  • CookiesFiles stored with the browserURLidentifying the originating siteCookie datasome data stringExpiration dateif no date, the cookie is not permanently storedsession cookie

  • 3rd party cookiesScenarioSite A adds a cookie to your browserURL: Site DCookie: visited site ASite BURL: Site DCookie: visited site Betc.Site D can build a cross-site profile of browsing behaviorBrowsers now report if a cookie's URL differs from its originthere are sometimes legitimate reasons for this

  • State management(OWASP A3)Cookie data can be forgedand in some cases, stolenDo not store any user data in the cookie itselfstore only a session idassociate id with data on the serverGood practiceuse a timeout to prevent hijackingprovide a logout option

  • State management, cont'dBrowser history may leave vulnerabilitieseven with logout, replay may still succeedattacker goes "back" to login page and resubmitsGood practiceissue hidden random id with each login pagedon't allow 2nd login with same iduse "no cache" headersbut don't rely on browser compliance

  • Command injection(OWASP A6)Web applications may access other applications resident on the serverdata is passed from a user's request to another applicationparameters can be designed to include commands that would otherwise not be permittedGood practicevalidate for legal data only

  • Example: shell escapePerl program$address = $query->('address');open( MAIL, "| /usr/lib/sendmail $address" );print MAIL "Your application has been received; thank you.\n"; close MAIL;What this doesthe program /usr/lib/sendmail is runwith $address as a parameterreceiving inpu