web application security ect 582 robin burke. outline ssl web appliation flaws configuration...
Post on 01-Jan-2016
Embed Size (px)
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
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"
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
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