OWASP Web Security Guide

OWASPTOP102007RELEASECANDIDATE1

THETENMOSTCRITICALWEBAPPLICATIONSECURITYVULNERABILITIES

2007UPDATE

©2002‐2007OWASPFoundation

ThisdocumentislicensedundertheCreativeCommonsAttribution‐ShareAlike2.5license

2

T A B L E O F C ON T EN T S

TableofContents ..................................................................................................................................................................2

Introduction ...........................................................................................................................................................................3

Summary ................................................................................................................................................................................4

Methodology .........................................................................................................................................................................5

A1–CrossSiteScripting(XSS) ..............................................................................................................................................8

A2–InjectionFlaws............................................................................................................................................................ 11

A3–MaliciousFileExecution ............................................................................................................................................ 13

A4–InsecureDirectObjectReference ............................................................................................................................. 17

A5–CrossSiteRequestForgery(CSRF) ............................................................................................................................ 19

A6–InformationLeakageandImproperErrorHandling ................................................................................................ 22

A7–BrokenAuthenticationandSessionManagement .................................................................................................. 24

A8–InsecureCryptographicStorage................................................................................................................................ 26

A9–InsecureCommunications......................................................................................................................................... 28

A10–FailuretoRestrictURLAccess................................................................................................................................. 30

WhereToGoFromHere.................................................................................................................................................... 32

References .......................................................................................................................................................................... 35

OWASPTop102007

3

I N T RO DUC T IO N

WelcometotheOWASPTop102007!Thistotallyre‐writteneditionliststhemostseriouswebapplicationvulnerabilities,discusseshowtoprotectagainstthem,andprovideslinkstomoreinformation.

AIM

TheprimaryaimoftheOWASPTop10 i stoeducatedevelopers, designers, architec tsandorganizationsabouttheconsequencesofthemostcommonwebapplicationsecurityvulnerabilities.TheTop10providesbasicmethodstoprotectagainstthesevulnerabilities–agreatstarttoyoursecurecodingsecurity

program.

Securi ty i snotaone‐timeevent .Itisinsufficienttosecureyourcodejustonce.By2008,thisTop10willhavechanged,andwithoutchangingalineofyourapplication’scode,youmaybevulnerable.Pleasereviewthe

adviceinWheretogofromhereformoreinformation.

Asecurecoding initiativemustdeal withal l stagesofaprogram’s l i fecycle .Securewebapplications

areonly possiblewhenasecureSDLCisused.Secureprogramsaresecurebydesign,duringdevelopment,andbydefault.Thereareatleast300issuesthataffecttheoverallsecurityofawebapplication.These300+issuesare

detailedintheOWASPGuide,whichisessentialreadingforanyonedevelopingwebapplicationstoday.

Thi sdocument i s f ir standforemostaneducationpiece, nota standard .Pleasedonotadoptthisdocumentasapolicyorstandardwithouttalkingtousfirst!Ifyouneedasecurecodingpolicyorstandard,OWASP

hassecurecodingpoliciesandstandardsprojectsinprogress.Pleaseconsiderjoiningorfinanciallyassistingwiththeseefforts.

4

SUMMARY

A1– CrossS iteSc ript ing (XSS) XSSflawsoccurwheneveranapplicationtakesusersupplieddataandsendsit

toawebbrowserwithoutfirstvalidatingorencodingthatcontent.XSSallowsattackerstoexecutescriptinthevictim’sbrowserwhichcanhijackuser

sessions,defacewebsites,etc.

A2– Inject ion Flaws Injectionflaws,particularlySQLinjection,arecommoninwebapplications.

Injectionoccurswhenuser‐supplieddataissenttoaninterpreteraspartofacommandorquery.Theattacker’shostiledatatrickstheinterpreterinto

executingunintendedcommandsorchangingdata.

A3– Insecure RemoteF ile

IncludeCodevulnerabletoremotefileinclusionallowsattackerstoincludehostile

codeanddata,resultingindevastatingattacks,suchastotalserver

compromise.

A4– Insecure DirectObjectReference

Adirectobjectreferenceoccurswhenadeveloperexposesareferencetoan

internalimplementationobject,suchasafile,directory,databaserecord,orkey,asaURLorformparameter.Attackerscanmanipulatethosereferencestoaccessotherobjectswithoutauthorization.

A5– CrossS iteRequest

Forgery(CSRF)ACSRFattackforcesalogged‐onvictim’sbrowsertosendapre‐authenticated

requesttoavulnerablewebapplication,whichthenforcesthevictim’sbrowser

toperformahostileactiontothebenefitoftheattacker.

A6– InformationLeakageandImproperErrorHandl ing

Applicationscanunintentionallyleakinformationabouttheirconfiguration,internalworkings,orviolateprivacythroughavarietyofapplicationproblems.

Attackersusethisweaknesstoviolateprivacy,orconductfurtherattacks.

A7– BrokenAuthenticationandSessionManagement

Accountcredentialsandsessiontokensareoftennotproperlyprotected.

Attackerscompromisepasswords,keys,orauthenticationtokenstoassumeotherusers’identities.

A8– Insecure Cryptograph icStorage

Webapplicationsrarelyusecryptographicfunctionsproperlytoprotectdata

andcredentials.Attackersuseweaklyprotecteddatatoconductidentitytheftandothercrimes,suchascreditcardfraud.

A9– Insecure Communications

Applicationsfrequentlyfailtoencryptnetworktrafficwhenitisnecessaryto

protectsensitivecommunications.

A10–Failure toRest rict URLAccess

Frequently,theonlyprotectionforsensitiveareasofanapplicationislinksor

URLsarenotpresentedtounauthorizedusers.Attackerscanusethisweaknesstoaccessandperformunauthorizedoperations.

Table1: Top10Webapp licationvu lnerabi lit ies for2006

OWASPTop102007

5

ME THODO LOG Y

OurmethodologyfortheTop102007wassimple:taketheMITREVulnerabilityTrendsfor2006,anddistilltheTop10webapplicationsecurityissues.Therankedresultsareasfollows:

Figure2: MITREdataonTop 10webapp licationvu lnerabi lit ies for2006

Althoughwehavetriedtopreservetheorder,wehavedeliberatelynotchosensomeweaknesses,suchasbufferoverflowsastheyarenotwidelyapplicabletowebapplicationsecurity.Inaddition,wehavetransformedsome

rawfindingsinto“meta”issuestofullycapturetherootcauseofanissuerepresentedbythatdata.

CrossSiteRequestForgery(CSRF)isthemajornewadditiontothiseditionoftheOWASPTop10.Althoughrawdataranksitat#36,wefeelthatitisimportantenoughthatapplicationsshouldstartprotectioneffortstoday,

particularlyforhighvalueapplicationsandapplicationswhichdealwithsensitivedata.

Wehavenotincludedlanguagespecific(C,C++,etc)issues,suchasbufferoverflows,formatstringattacks,oranyoftheothercommonweaknesseswhichplaguedesktopandserversoftware.Ifyouaredeliveringprogramsfor

desktoporserverplatforms,orareincludingtools,plug‐ins,orexternalprogramstobecalledbyyourwebapplication,westronglyrecommendyoureferencetheOWASPGuideandthebooksinthereferencessectionfor

moreinformationonhowtobuildorusethesesafely.

Alloftheprotectionrecommendationsprovidesolutionsforthethreemostprevalentwebapplication

frameworks:JavaEE,ASP.NET,andPHP.Othercommonwebapplicationframeworks,suchasRubyonRailsorPerlcaneasilyadapttherecommendationstosuittheirspecificneeds.

BIASES

ThemethodologydescribedabovenecessarilybiasestheTop10towardsdiscoveriesbythesecurityresearchercommunity.Thispatternofdiscoveryissimilartothemethodsofactualattack,particularlyasitrelatestoentry‐

level("scriptkiddy")attackers.ProtectingyoursoftwareagainsttheTop10willprovideamodicumofprotectionagainstthemostcommonformsofattack,butfarmoreimportantly,helpsetacourseforimprovingthesecurityof

yoursoftware.

6

MAPPING

Therehavebeenchangestotheheadings,evenwherecontentmapscloselytopreviouscontent.WenolongerusetheWASXMLnamingschemeasithasnotkeptuptodatewithmodernvulnerabilities,attacks,andcountermeasures.ThetablebelowdepictshowthiseditionmapstotheTop102004,andtherawMITREranking:

OWASPTop 102007 OWASPTop 102004 MITRE2006RawRanking

A1.CrossSite Scripting(XSS) A4.CrossSite Scripting(XSS) 1

A2.InjectionF laws A6.InjectionF laws 2

A3.InsecureRemote Fi le Include(NEW) 3

A4.InsecureD irectObjectReference A2.B rokenAccessCont rol (split in 2007T10) 5

A5.CrossSite RequestForgery(CSRF)(NEW) 36

A6.InformationLeakage and ImproperE rrorHandl ing

A7.ImproperE rrorHand ling 6

A7.B rokenAuthenticationandSession Management

A3.B rokenAuthenticationandSession Management

14

A8.InsecureCryptographicStorage A8.InsecureStorage 8

A9.InsecureCommunications(NEW) DiscussedunderA10.InsecureConf igurationManagement

8

A10.Fa iluretoRestr ict URLAccess A2.B rokenAccessCont rol (split in 2007T10) 14

A1.UnvalidatedInput 7

A5.BufferOverf lows 4,8, and10

A9.Den ialof Service 17

A10.InsecureConfiguration Management 29

WHYWEHAVEDROPPEDSOMEIMPORTANTISSUES

Unval idated inputisamajorchallengeforanydevelopmentteam,andisattherootofmanyapplicationsecurityproblems.Infact,manyoftheotheritemsinthelistrecommendvalidatinginputasapartofthesolution.

Westillstronglyrecommendcreatingacentralizedinputvalidationmechanismasapartofyourwebapplications.Formoreinformation,readthefollowingdatavalidationarticlesatOWASP:

http://www.owasp.org/index.php/Data_Validation http://www.owasp.org/index.php/Testing_for_Data_Validation

Bufferoverflows, integeroverflowsandformatstr ing issuesareextremelyseriousvulnerabilitiesforprogramswritteninlanguagessuchasCorC++.Remediationfortheseissuesiscoveredbythetraditionalnon‐webapplicationsecuritycommunity,suchasSANS,CERT,andprogramminglanguagetoolvendors.Ifyourcodeis

OWASPTop102007

7

writteninalanguagethatislikelytosufferbufferoverflows,weencourageyoutoreadthebufferoverflowcontentonOWASP:

http://www.owasp.org/index.php/Buffer_overflow http://www.owasp.org/index.php/Testing_for_Buffer_Overflow

Denial ofservice isaseriousattackthatcanaffectanysitewritteninanylanguage.TherankingofDoSbyMITREisinsufficienttomaketheTop10thisyear.Ifyouhaveconcernsaboutdenialofservice,youshouldconsult

theOWASPsiteandTestingGuide: http://www.owasp.org/index.php/Category:Denial_of_Service_Attack

http://www.owasp.org/index.php/Testing_for_Denial_of_Service

Insecureconfigurationmanagement affectsallsystemstosomeextent,particularlyPHP.However,therankingbyMITREdoesnotallowustoincludethisissuethisyear.Whendeployingyourapplication,youshould

consultthelatestOWASPGuideandtheOWASPTestingGuidefordetailedinformationregardingsecureconfigurationmanagementandtesting:

http://www.owasp.org/index.php/Configuration http://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management

VULNERABILITIES,NOTATTACKS

ThepreviouseditionoftheTop10containedamixtureofattacks,vulnerabilitiesandcountermeasures.Thistimearound,wehavefocusedsolelyonvulnerabilities.Iforganizationsusethisdocumenttosecuretheirapplications,

andreducetheriskstotheirbusiness,itwillleadtoadirectreductioninthelikelihoodof:

Phishingattacksthatcanexploitanyofthesevulnerabilities,particularlyXSS,andweakornon‐existentauthenticationorauthorizationchecks(A1,A4,A7,A10)

Privacyviolationsfrompoorvalidation,businessruleandweakauthorizationchecks(A2,A4,A6,A7,A10)

Identitytheftthroughpoorornon‐existentcryptographiccontrols(A8andA9),remotefileinclude(A3)andauthentication,businessrule,andauthorizationchecks(A4,A7,A10)

Systemscompromisethroughremotefileinclude(A3)andendofbusinessclassofdataalterationordestructionattacksviaInjections(A2)

FinanciallossthroughunauthorizedtransactionsandCSRFattacks(A4,A5,A7,A10)

Reputationlossthroughexploitationofanyoftheabovevulnerabilities(A1…A10)

Onceanorganizationmovesawayfromworryingaboutreactivecontrols,andmovesforwardtoproactivelyreducingrisksapplicabletotheirbusiness,theywillimprovecompliancewithregulatoryregimes,reduceoperationalcosts,andhopefullywillhavefarmorerobustandsecuresystemsasaresult.

ACKNOWLEDGEMENTS

WethanktheMITREProjectformakingVulnerabilityTypeDistributioninCVEdatafreelyavailableforuse.TheOWASPTopTenprojectisledandsponsoredbyAspect

Security.

8

A 1 – C RO S S S I T E S C R I P T I N G ( X S S )

Crosssitescripting,betterknownasXSS,isthemostprevalentandperniciouswebapplicationsecurityissue.XSSflawsoccurwheneveranapplicationtakesdatathatoriginatedfromauserandsendsittoawebbrowserwithoutfirstvalidatingorencodingthatcontent.

XSSallowsattackerstoexecutescriptinthevictim’sbrowser,whichcanhijackusersessions,defacewebsites,inserthostilecontent,conductphishingattacks,andtakeovertheuser’sbrowserusingscriptingmalware.ThemaliciousscriptisusuallyJavaScriptbutanyscriptinglanguagesupportedbythevictim’sbrowserisapotential

targetforthisattack.

ENVIRONMENTSAFFECTED

Allwebapplicationframeworksarevulnerabletocrosssitescripting.

VULNERABILITY

Therearethreeknowntypesofcrosssitescripting:reflected,stored,andDOMinjection.ReflectedXSSistheeasiesttoexploit–apagewillreflectusersupplieddatadirectlybacktotheuser:

echo $_REQUEST['userinput'];

StoredXSStakeshostiledata,storesitinafile,adatabase,orotherbackendsystem,andthenatalaterstage,displaysthedatatotheuser,unfiltered.ThisisextremelydangerousinsystemssuchasCMS,blogs,orforums,

wherealargenumberofuserswillseeinputfromotherindividuals.

WithDOMbasedXSSattacks,thesite’sJavaScriptcodeandvariablesaremanipulatedratherthanHTMLelements.Alternatively,attackscanbeablendorhybridofallthreetypes.Thedangerwithcrosssitescriptingisnotthetype

ofattack,butthatitispossible.

AttacksareusuallyimplementedinJavaScript,whichisapowerfulscriptinglanguage.UsingJavaScriptallowsattackerstomanipulateanyaspectoftherenderedpage,includingaddingnewelements(suchasaddingalogin

tilewhichforwardscredentialstoahostilesite),manipulatinganyaspectoftheinternalDOMtree,anddeletingorchangingthewaythepagelooksandfeels.JavaScriptallowstheuseofXmlHttpRequest,whichistypicallyusedby

sitesusingAJAXtechnologies,evenifvictimsitedoesnotuseAJAXtoday.

UsingXmlHttpRequest,itissometimespossibletogetaroundabrowser’ssamesourceoriginationpolicy‐thus

forwardingvictimdatatohostilesites,andtocreatecomplexwormsandmaliciouszombiesthatlastaslongasthebrowserstaysopen.AJAXattacksdonothavetobevisibleorrequireuserinteractiontoperformdangerouscross

siterequestforgery(CSRF)attacks(seeA‐5).

VERIFYINGSECURITY

Thegoalistoverifythatalltheparametersintheapplicationarevalidatedand/orencodedbeforebeingincludedinHTMLpages.

OWASPTop102007

9

Automatedapproaches:BothvulnerabilityscanningtoolsandstaticcodeanalysistoolscanfindsimpleXSSproblems,particularlyreflectedones.Theyfrequentlycan'tfindcomplexXSSflaws,suchaswhentheinjection

occursinapeculiarHTMLstructureorscript.TheyarealsonotlikelytofindinstancesofDOMbasedXSS.

Manualapproaches:Ifacentralizedvalidationandencodingmechanismisused,themostefficientwaytoverify

securityistocheckthecode.Ifadistributedimplementationisused,thentheverificationwillbeconsiderablymoretime‐consuming.Testingistime‐consumingbecausetheattacksurfaceofmostapplicationsissolarge.

PROTECTION

ThebestprotectionforXSSisacombinationof"whitelist"validationofallincomingdataandappropriateencodingofalloutputdata.Validationallowsthedetectionofattacks,andencodingpreventsanysuccessfulscriptinjection

fromrunninginthebrowser.

PreventingXSSacrossanentireapplicationrequiresaconsistentarchitecturalapproach:

Inputval idation. Useastandardinputvalidationmechanismtovalidateallinputdataforlength,type,

syntax,andbusinessrulesbeforeacceptingthedatatobedisplayedorstored.Usean"acceptknowngood"validationstrategy.Rejectinvalidinputratherthanattemptingtosanitizepotentiallyhostiledata.

Strongoutputencoding. Ensurethatalluser‐supplieddataisHTMLentityencodedbeforerendering

inHTML,takingtheapproachtoencodeallcharactersotherthanaverylimitedsubset.ThisistheapproachoftheMicrosoftAnti‐XSSlibrary,andtheforthcomingOWASPPHPAnti‐XSSlibrary.

Donotuse "blackl i st" val idationtodetectXSSininputortoencodeoutput.Searchingforandreplacingjustafewcharacters("<"">"andothersimilarcharacters)isweakandhasbeenattackedsuccessfully.

Languagespecificrecommendations:

Java:UseStrutsoutputmechanismssuchas<bean:write…>,orusethedefaultJSTLescapeXML="true"attributein<c:out…>.DoNOTuse<%=…%>unnested(thatis,outsideofaproperlyencodedoutput

mechanism).

.NET:UsetheMicrosoftAnti‐XSSLibrary1.5freelyavailablefromMSDN.DonotassignformfieldsdatadirectlyfromtheRequestobject:username.Text = Request.QueryString("username");withoutusing

thislibrary.Understandwhich.NETcontrolsautomaticallyencodeoutputdata.

PHP:Ensureoutputispassedthroughhtmlentities()orhtmlspecialchars()orusethesoontobereleasedOWASPPHPAnti‐XSSlibrary.

SAMPLES http://cve.mitre.org/cgi‐bin/cvename.cgi?name=CVE‐2006‐4206

http://cve.mitre.org/cgi‐bin/cvename.cgi?name=CVE‐2005‐3966 http://cve.mitre.org/cgi‐bin/cvename.cgi?name=CVE‐2006‐5204

REFERENCES OWASP–Crosssitescripting,http://www.owasp.org/index.php/Cross_Site_Scripting

OWASP–TestingforXSS,http://www.owasp.org/index.php/Testing_for_Cross_site_scripting

10

OWASPStingerProject(AJavaEEvalidationfilter)–http://www.owasp.org/index.php/Category:OWASP_Stinger_Project

OWASPPHPFilterProject‐http://www.owasp.org/index.php/OWASP_PHP_Filters OWASPEncodingProject‐http://www.owasp.org/index.php/Category:OWASP_Encoding_Project

RSnake,XSSCheatSheet,http://ha.ckers.org/xss.html Klein,A.,DOMBasedCrossSiteScripting,http://www.webappsec.org/projects/articles/071105.shtml

.NETAnti‐XSSLibrary‐http://www.microsoft.com/downloads/details.aspx?FamilyID=efb9c819‐53ff‐4f82‐bfaf‐e11625130c25&DisplayLang=en

OWASPTop102007

11

A 2 – I N J E C T IO N F L AW S

Injectionflaws,particularlySQLinjection,arecommoninwebapplications.Injectionoccurswhenuser‐supplieddataissenttoaninterpreteraspartofacommandorquery.Theattacker’sdatatrickstheinterpreterintoexecutingunintendedcommands.Injectionflawsallowattackerstocreate,read,update,ordeleteanyarbitrary

dataavailabletotheapplication.Intheworstcasescenario,theseflawsallowanattackertocompletelycompromisetheapplication.


Allwebapplicationframeworksthatuseinterpretersarevulnerabletoinjectionattacks.

VULNERABILITY

Ifuserinputispassedintoaninterpreterwithoutvalidationorencoding,theapplicationisvulnerable.Checkifuserinputissuppliedtodynamicqueries,suchas:

$sql = "SELECT * FROM table WHERE id = '" . $_REQUEST['id’] . "’";

VERIFYINGSECURITY

Thegoalistoverifythatuserdatacannotmodifythemeaningofcommandsandqueriessenttoanyoftheinterpretersinvokedbytheapplication.

Automatedapproaches:Manyvulnerabilityscanningtoolssearchforinjectionproblems,particularlySQLinjection.

Detectingwhethertheinjectionworkedornotisdifficultandpronetoerror.StaticanalysistoolsthatsearchforusesofunsafeinterpreterAPIsareuseful,butfrequentlycannotverifythatappropriatevalidationorencoding

mightbeinplacetoprotectagainstthevulnerability.

Manualapproaches:Themostefficientandaccurateapproachistocheckthecodethatinvokesinterpreters.ThereviewershouldverifytheuseofasafeAPIorthatappropriatevalidationand/orencodinghasoccurred.Testing

canbeextremelytime‐consumingandspottybecausetheattacksurfaceofmostapplicationsissolarge.

PROTECTION

Avoidtheuseofinterpreterswhenpossible.Ifyoumustinvokeaninterpreter,thekeymethodtoavoidinjectionsistheuseofsafeAPIs,suchasstronglytypedparameterizedqueriesandobjectrelationalmapping(ORM)libraries.Theseinterfaceshandlealldataescaping,ordonotrequireescaping.Notethatwhilesafeinterfacessolvethe

problem,validationisstillrecommendedinordertodetectattacks.

Usinginterpretersisdangerous,soit'sworthittotakeextracare,suchasthefollowing:

Enforce leastprivi lege whenconnectingtodatabasesandotherbackendsystems

Avoiddetai lederrormessagesthatareusefultoanattacker

Donotsenddynamicqueries intoaparameterizedinterface

Becareful whenusing storedproceduresastheycanbeinjectable

12

Donotusedynamicquery inter faces(suchasmysql_query()orsimilar)

Donotuse simpleescapingfunctions,suchasPHP’saddslashes()orcharacterreplacement

functionslikestr_replace("’","’’").Theseareweakandhavebeensuccessfullyexploitedbyattackers.

Languagespecificrecommendations: JavaEE–usestronglytypedPreparedStatement,orORMssuchasHibernateorSpring

.NET–usestronglytypedparameterizedqueries,suchasSqlCommandwithSqlParameteroranORMlikeHibernate.

PHP–usePDOwithstronglytypedparameterizedqueries(usingbindParam())

SAMPLES


http://cve.mitre.org/cgi‐bin/cvename.cgi?name=CVE‐2006‐4592

REFERENCES

OWASP,http://www.owasp.org/index.php/SQL_Injection

OWASP,http://www.owasp.org/index.php/Guide_to_SQL_Injection

OWASP,http://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection

OWASP,http://www.owasp.org/index.php/Testing_for_SQL_Injection

SQLInjection,http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf

AdvancedSQLInjection,http://www.ngssoftware.com/papers/advanced_sql_injection.pdf

MoreAdvancedSQLInjection,http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf

Hibernate,anadvancedobjectrelationalmanager(ORM)forJ2EEand.NET,http://www.hibernate.org/

J2EEPreparedStatements,http://java.sun.com/docs/books/tutorial/jdbc/basics/prepared.html

Howto:ProtectfromSQLinjectioninASP.Net,http://msdn2.microsoft.com/en‐us/library/ms998271.aspx

PHPPDOfunctions,http://php.net/pdo

OWASPTop102007

13

A 3 – MA L I C I OU S F I L E E X E C UT I ON

Maliciousfileexecutionvulnerabilitiesarefoundinmanyapplications.Developerswilloftendirectlyuseorconcatenatepotentiallyhostileinputwithfileorstreamfunctions,orimproperlytrustinputfiles.Onmanyplatforms,frameworksallowtheuseofexternalobjectreferences,suchasURLsorfilesystemreferences.When

thedataisinsufficientlychecked,thiscanleadtoarbitraryremoteandhostilecontentbeingincluded,processedorinvokedbythewebserver.

Thisallowsattackerstoperform:

Remotecodeexecution

Remoterootkitinstallationandcompletesystemcompromise

OnWindows,internalsystemcompromisemaybepossiblethroughtheuseofPHP’sSMBfilewrappers

ThisattackisparticularlyprevalentonPHP,andextremecaremustbetakenwithanystreamorfilefunctiontoensurethatusersuppliedinputdoesnotinfluencefilenames.


Allwebapplicationframeworksthatallowuploadedfilestobeexecutedarevulnerabletoremotefileinclude.By

default,PHP4.0.4andlaterand5.xarevulnerabletoremotefileinclusion.Otherenvironmentsaresusceptibleiftheyallowfileuploadintowebdirectories.

VULNERABILITY

Acommonvulnerableconstructis:

include $_REQUEST['filename’];

Notonlydoesthisallowevaluationofremotehostilescripts,itcanbeusedtoaccesslocalfileservers(ifPHPishosteduponWindows)duetoSMBsupportinPHP’sfilesystemwrappers.

Othermethodsofattackinclude:

Hostiledatabeinguploadedtosessionfiles,logdata,andviaimageuploads(typicalofforumsoftware)

Usingcompressionoraudiostreams,suchaszlib://orogg://whichdonotinspecttheinternalPHPURLflagandthusallowaccesstoremoteresourcesevenifallow_url_fopenorallow_url_includeisdisabled

UsingPHPwrappers,suchasphp://inputandotherstotakeinputfromtherequestPOSTdataratherthanafile

UsingPHP’sdata:wrapper,suchasdata:;base64,PD9waHAgcGhwaW5mbygpOz8+

Asthislistisextensive(andperiodicallychanges),itisvitaltouseaproperlydesignedsecurityarchitectureandrobustdesignwhendealingwithusersuppliedinputsinfluencingthechoiceofserversidefilenamesandaccess.

14

AlthoughPHPexampleshavebeengiven,thisattackisalsoapplicableindifferentwaysto.NETandJ2EE.Applicationswritteninthoseframeworksneedtopayparticularattentiontocodeaccesssecuritymechanismsto

ensurethatfilenamessuppliedbyorinfluencedbytheuserdonotallowsecuritycontrolstobeobviated.

Forexample,itispossiblethatXMLdocumentssubmittedbyanattackerwillhaveahostileDTDthatforcesthe

XMLparsertoloadaremoteDTD,andparseandprocesstheresults.AnAustraliansecurityfirmhasdemonstratedthisapproachtoportscanningbehindfirewalls.See[SIF01]inthischapter’sreferencesformoreinformation.

Thedamagethisparticularvulnerabilitycausesisdirectlyrelatedtothestrengthofthesandbox/platformisolationcontrolsintheframework.AsPHPisrarelyisolatedandhasnosandboxconceptorsecurityarchitecture,thedamageisfarworseforanattackthanotherplatformswithlimitedorpartialtrust,orarecontainedwithina

suitablesandbox,suchaswhenawebappisrunningunderaJVMwiththesecuritymanagerproperlyenabledandconfigured(whichisrarelythedefault).

VERIFYINGSECURITY

Automatedapproaches:Vulnerabilityscanningtoolswillhavedifficultyidentifyingtheparametersthatareusedinafileincludeorthesyntaxformakingthemwork.StaticanalysistoolscansearchfortheuseofdangerousAPIs,

butcannotverifythatappropriatevalidationorencodingmightbeinplacetoprotectagainstthevulnerability.

Manualapproaches:Acodereviewcansearchforcodethatmightallowafiletobeincludedintheapplication,buttherearemanypossiblemistakestorecognize.Testingcanalsodetectthesevulnerabilities,butidentifyingthe

particularparametersandtherightsyntaxcanbedifficult.

PROTECTION

Preventingremotefileincludeflawstakessomecarefulplanningatthearchitecturalanddesignphases,throughtothoroughtesting.Ingeneral,awell‐writtenapplicationwillnotuseuser‐suppliedinputinanyfilenameforany

server‐basedresource(suchasimages,XMLandXSLtransformdocuments,orscriptinclusions),andwillhavefirewallrulesinplacepreventingnewoutboundconnectionstotheInternetorinternallybacktoanyotherserver.

However,manylegacyapplicationswillcontinuetohaveaneedtoacceptusersuppliedinput.

Amongthemostimportantconsiderationsare:

Consideravariablenamingschemetoassistwithtaintchecking:

$hostile = &$_POST; // refer to POST variables, not $_REQUEST

$safe[‘filename’]= validate_file_name($hostile[‘unsafe_filename’]); // make it safe

Thereforeanyoperationbaseduponhostileinputisimmediatelyobvious:

require_once($_POST[‘unsafe_filename’] . ‘inc.php’);

require_once($safe[‘filename’] . ‘inc.php’);

Stronglyvalidateuserinputusing"acceptknowngood"asastrategy

Hideserver‐sidefilenamesfromtheuser.Forexample,insteadofincluding$language.".lang.php",use

anarrayindexlikethis:

OWASPTop102007

15

<select name="language"><option value="1">Français</option></select>

…

$language = intval($_POST['language’]);

if ($language > 0) {

require_once($lang[$language]); // lang is array of strings eg "fr.lang.php"

}

Disableallow_url_fopenandallow_url_includeinphp.iniandconsiderbuildingPHPlocallytonotincludethisfunctionality.

Addfirewallrulestopreventwebserversmakingnewconnectionstoexternalwebsitesandinternalsystems.Forhighvaluesystems,isolatethewebserverinitsownVLANorprivatesubnet.

Ensurethatfileandstreamsfunctions(stream_*)arecarefullyvetted.Ensurethattheuserinputisnotsuppliedanyfunctionwhichtakesafilenameargument,including:

include() include_once() require() require_once() fopen() imagecreatefromXXX() file() file_get_contents() copy() delete() unlink() upload_tmp_dir() $_FILES move_uploaded_file()

Beextremelycautiousifdataispassedtosystem()eval()passthru()or`(thebacktickoperator).

Checkthatanyfilestakenfromtheuserforlegitimatepurposescannotbeotherwiseobviated,suchasincludingusersupplieddatainthesessionobject,avatarsandimages,PDFreports,temporaryfiles,andsoon.

WithPHP,considerimplementingachrootjailorothersandboxmechanismssuchasvirtualizationtoisolateapplicationsfromeachother

WithJ2EE,ensurethatthesecuritymanagerisenabledandproperlyconfiguredandthattheapplicationisdemandingpermissionsappropriately

WithASP.NET,pleaserefertothedocumentationonpartialtrust,anddesignyourapplicationstobesegmentedintrust,sothatmostoftheapplicationexistsinthelowestpossibletruststatepossible



REFERENCES

OWASPGuide,http://www.owasp.org/index.php/File_System#Includes_and_Remote_files

OWASPTestingGuide,http://www.owasp.org/index.php/Testing_for_Directory_Traversal

OWASPPHPTop5,http://www.owasp.org/index.php/PHP_Top_5#P1:_Remote_Code_Execution

16

StefanEsser,http://blog.php‐security.org/archives/45‐PHP‐5.2.0‐and‐allow_url_include.html

[SIF01]SiftNetworks,WebServices:Teachinganolddognewtricks,http://www.ruxcon.org.au/files/2006/web_services_security.ppt

http://www.owasp.org/index.php/OWASP_Java_Table_of_Contents#Defining_a_Java_Security_Policy

Microsoft‐ProgrammingforPartialTrust,http://msdn2.microsoft.com/en‐us/library/ms364059(VS.80).aspx

OWASPTop102007

17

A 4 – I N SE CU RE D I R E C T O B J E C T R E FE RE N CE

Adirectobjectreferenceoccurswhenadeveloperexposesareferencetoaninternalimplementationobject,suchasafile,directory,databaserecord,orkey,asaURLorformparameter.Unlessanaccesscontrolcheckisinplace,anattackercanmanipulatethosereferencestoaccessotherobjectswithoutauthorization.


Allwebapplicationframeworksarevulnerabletoattacksoninsecuredirectobjectreferences.

VULNERABILITY

Manyapplicationsexposetheirinternalobjectreferencestousers.Attackersuseparametertamperingtochangereferencesandviolatetheintendedbutunenforcedaccesscontrolpolicy.Frequently,thesereferencespointtofilesystemsanddatabases,butanyexposedapplicationconstructcouldbevulnerable.

Forexample,ifcodeallowsuserinputtospecifyfilenamesorpaths,itmayallowattackerstojumpoutoftheapplication’sdirectory,andaccessotherresources.

<select name="language"><option value="fr">Français</option></select>

…

require_once ($_REQUEST['language’]."lang.php");

Suchcodecanbeattackedusingastringlike"../../../../etc/passwd%00"usingnullbyteinjection(seetheOWASPGuideformoreinformation)toaccessanyfileonthewebserver’sfilesystem.

Similarly,referencestodatabasekeysarefrequentlyexposed.Anattackercanattacktheseparameterssimplyby

guessingorsearchingforanothervalidkey.Often,thesearesequentialinnature.Intheexamplebelow,evenifanapplicationdoesnotpresentanylinkstounauthorizedcarts,andnoSQLinjectionispossible,anattackercanstill

changethecartIDparametertowhatevercarttheywant.

int cartID = Integer.parseInt( request.getParameter( "cartID" ) );

String query = "SELECT * FROM table WHERE cartID=" + cartID;

VERIFYINGSECURITY

Thegoalistoverifythattheapplicationdoesnotallowdirectobjectreferencestobemanipulatedbyanattacker.

Automatedapproaches:Vulnerabilityscanningtoolswillhavedifficultyidentifyingwhichparametersaresusceptibletomanipulationorwhetherthemanipulationworked.Staticanalysistoolsreallycannotknowwhichparametersmusthaveanaccesscontrolcheckbeforeuse.

Manualapproaches:Codereviewcantracecriticalparametersandidentifywhethertheyaresusceptibletomanipulationinmanycases.Penetrationtestingcanalsoverifythatmanipulationispossible.However,bothof

thesetechniquesaretime‐consumingandcanbespotty.

18

PROTECTION

Thebestprotectionistoavoidexposingdirectobjectreferencestousersbyusinganindex,map,orotherindirectmethodthatiseasytovalidate.Ifadirectobjectreferencemustbeused,ensurethattheuserisauthorizedbeforeusingit.

Establishingastandardwayofreferringtoapplicationobjectsisimportant: Avoidexposingyourprivateobjectreferencestouserswheneverpossible

Validateanyprivateobjectreferencesextensivelywithan"acceptknowngood"approach Verifyauthorizationtoallreferencedobjects

Ifyoumustexposeafilesystemreference,useanindexvalueoramaptopreventpathandfilenamemanipulation.

http://www.example.com/application?file=1

Ifyoumustexposedirectreferencestodatabasestructures,ensurethatSQLstatementsandotherdatabaseaccessmethodsonlyallowauthorizedrecordstobeshown:

int cartID = Integer.parseInt( request.getParameter( "cartID" ) );

User user = (User)request.getSession().getAttribute( "user" );

String query = "SELECT * FROM table WHERE cartID=" + cartID + " AND userID=" + user.getID();

SAMPLES



REFERENCES

OWASP,http://www.owasp.org/index.php/Testing_for_business_logic

OWASP,http://www.owasp.org/index.php/Testing_for_Directory_Traversal

OWASP,http://www.owasp.org/index.php/Category:Access_Control_Vulnerability

OWASPTop102007

19

A 5 – C RO S S S I T E R E QUE ST FO RGE RY ( C SR F )

Crosssiterequestforgeryisnotanewattack,butissimpleanddevastating.ACSRFattackforcesalogged‐onvictim’sbrowsertosendarequesttoavulnerablewebapplication,whichthenperformsthechosenactiononbehalfofthevictim,tothebenefitoftheattacker.Thisvulnerabilityisextremelywidespread,asanyweb

applicationthatauthorizesrequestsbasedonlyoncredentialsthatareautomaticallysubmittedbythebrowserisvulnerable.Unfortunately,today,mostwebapplicationsrelysolelyonautomaticallysubmittedcredentialssuchas

sessioncookies,BasicAuthenticationcredentials,sourceIPaddresses,SSLcertificates,Windowsdomaincredentials,etc.

ThisvulnerabilityisalsoknownbyseveralothernamesincludingSessionRiding,One‐ClickAttacks,CrossSiteReferenceForgery,HostileLinking,andAutomationAttack.TheacronymXSRFisalsofrequentlyused.OWASPandMITREhavebothstandardizedonthetermCrossSiteRequestForgeryandCSRF.


AllwebapplicationframeworksarevulnerabletoCSRF.

VULNERABILITY

AtypicalCSRFattackagainstaforummighttaketheformofdirectingtheusertoinvokesomefunction,suchastheapplication’slogoutpage.Thefollowingtaginanywebpageviewedbythevictimwillgeneratearequestwhichlogsthemout:

<img src="http://www.example.com/logout.php">

Ifanonlinebankalloweditsapplicationtoprocessrequests,suchastransferfunds,asimilarattackmightallow:

<img src="http://www.example.com/transfer.do?frmAcct=document.form.frmAcct &toAcct=4345754&toSWIFTid=434343&amt=3434.43">

Bothoftheseattacksworkbecausetheuser’sauthorizationcredential(typicallythesessioncookie)wouldautomaticallybeincludedwithsuchrequestsbythebrowser,eventhoughtheattackerdidn’tsupplythatcredential.

Ifthetagcontainingtheattackcanbepostedtoavulnerableapplication,thenthelikelihoodoffindingloggedinvictimsissignificantlyincreased,similartotheincreaseinriskbetweenstoredandreflectedXSSflaws.XSSflawsarenotrequiredforaCSRFattacktowork,althoughanyapplicationwithXSSflawsissusceptibletoCSRFbecause

aCSRFattackcanexploittheXSSflawtostealanynon‐automaticallysubmittedcredentialthatmightbeinplacetoprotectagainstaCSRFattack.Manyapplicationwormshaveusedbothtechniquesincombination.

WhenbuildingdefensesagainstCSRFattacks,youmustalsofocusoneliminatingXSSvulnerabilitiesinyourapplicationsincesuchflawscanbeusedtogetaroundmostCSRFdefensesyoumightputinplace.

VERIFYINGSECURITY

ThegoalistoverifythattheapplicationprotectsagainstCSRFattacksbygeneratingandthenrequiringsometypeofauthorizationtokenthatisnotautomaticallysubmittedbythebrowser.

20

Automatedapproaches:VulnerabilityscannersshouldbeabletodetectthelackofCSRFprotectioninapplicationswithalittlebitoftraining.Staticanalysistools,ontheotherhand,willhaveadifficulttimerecognizingacustom

mechanismforprotectingagainstthisattack.

Manualapproaches:PenetrationtestingisaquickwaytoverifythatCSRFprotectionisinplace.Toverifythatthe

mechanismisstrongandproperlyimplemented,checkingthecodeisthemostefficientcourse.

PROTECTION

Applicationsmustensurethattheyarenotrelyingoncredentialsortokensthatareautomaticallysubmittedbybrowsers.Theonlysolutionistouseacustomtokenthatthebrowserwillnot‘remember’andthenautomaticallyincludewithaCSRFattack.

Thefollowingstrategiesshouldbeinherentinallwebapplications:

EnsurethattherearenoXSSvulnerabilitiesinyourapplication(seeA1–CrossSiteScripting)

InsertcustomrandomtokensintoeveryformandURLthatwillnotbeautomaticallysubmittedbythebrowser.Forexample,

<form action="/transfer.do" method="post">

<input type="hidden" name="8438927730" value="43847384383">

… </form>

andthenverifythatthesubmittedtokeniscorrectforthecurrentuser.Suchtokenscanbeuniquetothat

particularfunctionorpageforthatuser,orsimplyuniquetotheoverallsession.Themorefocusedthetokenistoaparticularfunctionand/orparticularsetofdata,thestrongertheprotectionwillbe,butthe

morecomplicateditwillbetoconstructandmaintain.

Forsensitivedataorvaluetransactions,re‐authenticateorusetransactionsigningtoensurethattherequestisgenuine.Considersendingane‐mailorphoningthecustomeriftheactivityseemssuspicious,

toalerttheuserandpotentiallybackoutthetransaction.

DonotuseGETrequests(URLs)forsensitivedataortoperformvaluetransactions.UseonlyPOSTmethodswhenprocessingsensitivedatafromtheuser.

ForASP.NET, setaViewStateUserKey. (Seereferences).Thisprovidesasimilartypeofchecktoarandomtokenasdescribedabove.

Whilethesesuggestionswilldiminishyourexposuredramatically,advancedCSRFattackscanbypassmanyof

theserestrictions.Thestrongesttechniqueistheuseofuniquetokens,andeliminatingallXSSvulnerabilitiesinyourapplication.

SAMPLES http://cve.mitre.org/cgi‐bin/cvename.cgi?name=CVE‐2007‐0192 http://cve.mitre.org/cgi‐bin/cvename.cgi?name=CVE‐2006‐5116

MySpaceWormExplanationhttp://namb.la/popular/tech.html

OWASPTop102007

21

AnattackwhichusesQuicktimetoperformCSRFattackshttp://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9005607&intsr

c=hm_list

REFERENCES

OWASPCSRF,http://www.owasp.org/index.php/Cross‐Site_Request_Forgery

OWASP,https://www.owasp.org/index.php/Testing_for_CSRF

OWASPCSRFGuard,http://www.owasp.org/index.php/CSRF_Guard

OWASPPHPCSRFGuard,http://www.owasp.org/index.php/PHP_CSRF_Guard

RSnake,"WhatisCSRF?",http://ha.ckers.org/blog/20061030/what‐is‐csrf/

Microsoft,ViewStateUserKeydetails,http://msdn2.microsoft.com/en‐us/library/ms972969.aspx#securitybarriers_topic2

22

A 6 – I N FO RMAT ION L E AK AGE AND IM P RO PE R E R RO R HANDL IN G

Applicationscanunintentionallyleakinformationabouttheirconfiguration,internalworkings,orviolateprivacythroughavarietyofapplicationproblems.Applicationscanalsoleakinternalstateviahowlongtheytaketoprocesscertainoperationsorviadifferentresponsestodifferinginputs,suchasdisplayingthesameerrortextwith

differenterrornumbers.Webapplicationswilloftenleakinformationabouttheirinternalstatethroughdetailedordebugerrormessages.


Allwebapplicationframeworksarevulnerabletoinformationleakageandimpropererrorhandling.

VULNERABILITY

Applicationsfrequentlygenerateerrormessagesanddisplaythemtousers.Manytimestheseerrormessagesarequiteusefultoattackers,astheyrevealimplementationdetailsorinformationthatisusefulinexploringavulnerability.Thereareseveralcommonexamplesofthis:

Detailederrorhandling,whereinducinganerrordisplaystoomuchinformation,suchasstacktraces,failedSQLstatements,orotherdebugginginformation.

Functionsthatproducedifferentresultsbasedupondifferentinputs.Forexample,supplyingthesame

usernamebutdifferentpasswordstoaloginfunctionshouldproducethesametextfornosuchuser,andbadpassword.However,manysystemsproducedifferenterrorcodes.

VERIFYINGSECURITY

Thegoalistoverifythattheapplicationdoesnotleakinformationviaerrormessagesorothermeans.

Automatedapproaches:Vulnerabilityscanningtoolscanandprobablywillcauseerrormessagestobegenerated.Detectingwhetherthemessagesleakinformationisthechallenge.Staticanalysistoolscansearchfortheuseof

APIsthatleakinformation,butwillnotbeabletoverifythemeaningofthosemessages.

Manualapproaches:Acodereviewcansearchforimpropererrorhandlingandotherpatternsthatleakinformation,butitistime‐consuming.Testingwillalsogenerateerrormessages,butknowingwhaterrorpaths

werecoveredisachallenge.

PROTECTION

DevelopersshouldusetoolslikeOWASP'sWebScarabtotrytomaketheirapplicationgenerateerrors.Applicationsthathavenotbeentestedinthiswaywillalmostcertainlygenerateunexpectederroroutput.Applicationsshould

alsoincludeastandardexceptionhandlingarchitecturetopreventunwantedinformationfromleakingtoattackers.

Preventinginformationleakagerequiresdiscipline.Thefollowingpracticeshaveproveneffective: Ensurethattheentiresoftwaredevelopmentteamsharesacommonapproachtoexceptionhandling.

Disableorlimitdetailederrorhandling.Inparticular,donotdisplaydebuginformationtoendusers,stacktraces,orpathinformation.

OWASPTop102007

23

Ensurethatsecurepathsthathavemultipleoutcomesreturnsimilaroridenticalerrormessagesinroughlythesametime.Ifthisisnotpossible,considerimposingarandomwaittimeforalltransactionsto

hidethisdetailfromtheattacker.

SAMPLES



REFERENCES

OWASP,http://www.owasp.org/index.php/Error_Handling

OWASP,http://www.owasp.org/index.php/Category:Sensitive_Data_Protection_Vulnerability

24

A 7 – B RO KE N A UT HEN T I CA T IO N A ND S E S S ION MANAGEMEN T

Properauthenticationandsessionmanagementiscriticaltowebapplicationsecurity.Flawsinthisareamostfrequentlyinvolvethefailuretoprotectcredentialsandsessiontokensthroughtheirlifecycle.Theseflawscanleadtothehijackingofuseroradministrativeaccounts,undermineauthorizationandaccountabilitycontrols,andcause

privacyviolations.


Allwebapplicationframeworksarevulnerabletoauthenticationandsessionmanagementflaws.

VULNERABILITY

Flawsinthemainauthenticationmechanismarenotuncommon,butweaknessesaremoreoftenintroducedthroughancillaryauthenticationfunctionssuchaslogout,passwordmanagement,timeout,rememberme,secret

question,andaccountupdate.

VERIFYINGSECURITY

Thegoalistoverifythattheapplicationproperlyauthenticatesusersandproperlyprotectsidentitiesandtheirassociatedcredentials.

Automatedapproaches:Vulnerabilityscanningtoolshaveaverydifficulttimedetectingvulnerabilitiesincustom

authenticationandsessionmanagementschemes.Staticanalysistoolsarealsonotlikelytodetectauthenticationandsessionmanagementproblemsincustomcode.

Manualapproaches:Codereviewandtesting,especiallyincombination,arequiteeffectiveatverifyingthattheauthentication,sessionmanagement,andancillaryfunctionsareallimplementedproperly.

PROTECTION

Authenticationreliesonsecurecommunicationandcredentialstorage.FirstensurethatSSListheonlyoptionforallauthenticatedpartsoftheapplication(seeA9–InsecureCommunications)andthatallcredentialsarestoredinhashedorencryptedform(seeA8–InsecureCryptographicStorage).

Preventingauthenticationflawstakescarefulplanning.Amongthemostimportantconsiderationsare:

Useasingleauthenticationmechanismwithappropriatestrengthandnumberoffactors Usethecontainerprovidedsessionmanagementmechanismandnocustomcookies

Createanewsessionuponsuccessfulauthentication Ensurethateverypagehasalogoutlink,andthatlogoutdestroysallserversidesessionstateandclient

sidecookies Ensureancillaryauthenticationfunctions(questionsandanswers,passwordreset)areasstrongasthe

mainonesanddon'tcontainflaws DonotexposeanycredentialsinURLsorlogs(nosessionrewriting)

OWASPTop102007

25

SAMPLES



REFERENCES

OWASP,http://www.owasp.org/index.php/Guide_to_Authentication OWASP,http://www.owasp.org/index.php/Reviewing_Code_for_Authentication

OWASP,http://www.owasp.org/index.php/Testing_for_authentication

26

A 8 – I N SE CU RE C RY P TO GRA PH I C S TO RAG E

Protectingsensitivedatawithcryptographyhasbecomeakeypartofmostwebapplications.Simplyfailingtoencryptsensitivedataisverywidespread.Applicationsthatdoencryptfrequentlycontainpoorlydesignedcryptography,eitherusinginappropriateciphersormakingseriousmistakesusingstrongciphers.Theseflawscan

leadtodisclosureofsensitivedataandcomplianceviolations.


Allwebapplicationframeworksarevulnerabletoinsecurecryptographicstorage.

VULNERABILITY

Preventingcryptographicflawstakescarefulplanning.Themostcommonproblemsare:

Notencryptingsensitivedata

Usinghomegrownalgorithms

Insecureuseofstrongalgorithms

Continueduseofprovenweakalgorithms(MD5,SHA‐1,RC3,RC4,etc…)

Hardcodingkeys,andstoringkeysinunprotectedstores

VERIFYINGSECURITY

Thegoalistoverifythattheapplicationproperlyencryptssensitiveinformationinstorage.

Automatedapproaches:Vulnerabilityscanningtoolscannotverifycryptographicstorageatall.CodescanningtoolscandetectuseofknowncryptographicAPIs,butcannotdetectifitisbeingusedproperlyoriftheencryptionisperformedinanexternalcomponent.

Manualapproaches:Likescanning,testingcannotverifycryptographicstorage.Codereviewisthebestwaytoverifythatanapplicationencryptssensitivedataandhasproperlyimplementedthemechanismandkeymanagement.Thismayinvolvetheexaminationoftheconfigurationofexternalsystemsinsomecases.

PROTECTION

Themostimportantaspectistoensurethateverythingthatshouldbeencryptedisactuallyencrypted.Thenyou

mustensurethatthecryptographyisimplementedproperly.Astherearesomanywaysofusingcryptographyimproperly,thefollowingrecommendationsshouldbetakenaspartofyourtestingregimetohelpensuresecure

cryptographicmaterialshandling:

Donotallowunqualifiedstafftotrytocreatecryptographicalgorithms.UseonlyapprovedpublicalgorithmssuchasAES,RSApublickeycryptography,andSHA‐256orbetterforhashing.

Donotuseweakalgorithms,suchasMD5/SHA1.Favorsaferalternatives,suchasSHA‐256orbetter.

OWASPTop102007

27

Generatekeysofflineandstoreprivatekeyswithextremecare

EnsurethatinfrastructurecredentialssuchasdatabasecredentialsorMQqueueaccessdetailsare

securelyencryptedandnoteasilydecryptedbylocalorremoteusers

Ensurethatencrypteddatastoredondiskisnoteasytodecrypt.Forexample,databaseencryptionisworthlessifthedatabaseconnectionpoolprovidesunencryptedaccess.Allthisdoesisslowdownthe

databaseandmakequeriesveryslow.

UnderPCIDataSecurityStandardrequirement3,youmustprotectcardholderdata.PCIDSScomplianceismandatoryby2008formerchantsandanyoneelsedealingwithcreditcards.Goodpracticeistonever

storeunnecessarydata,suchasthemagneticstripeinformationortheprimaryaccountnumber(PAN,otherwiseknownasthecreditcardnumber).IfyoustorethePAN,theDSScompliancerequirementsare

heftyandcontinuing.Forexample,youareNEVERallowedtostoretheCVVnumber(thethreedigitnumberontherearofthecard)underanycircumstances.Formoreinformation,pleaseseethePCIDSS

Guidelinesandimplementcontrolsasnecessary.

SAMPLES


http://cve.mitre.org/cgi‐bin/cvename.cgi?name=CVE‐1999‐1101(TrueofmostJavaEEservletcontainers,too)

REFERENCES

OWASP,http://www.owasp.org/index.php/Cryptography

OWASP,http://www.owasp.org/index.php/Guide_to_Cryptography

OWASP,http://www.owasp.org/index.php/Insecure_Storage

OWASP,http://www.owasp.org/index.php/How_to_protect_sensitive_data_in_URL’s

PCIDataSecurityStandardv1.1,https://www.pcisecuritystandards.org/pdfs/pci_dss_v1‐1.pdf

BruceSchneier,http://www.schneier.com/

CryptoAPINextGeneration,http://msdn2.microsoft.com/en‐us/library/aa376210.aspx

28

A 9 – I N SE CU RE COMMUN IC A T ION S

Applicationsfrequentlyfailtoencryptnetworktrafficwhenitisnecessarytoprotectsensitivecommunications.Encryption(usuallySSL)mustbeusedforallauthenticatedconnections,especiallyinternetaccessiblewebpagesbutbackendconnectionsaswell.Otherwise,theapplicationwillexposeanauthenticationorsessiontoken.In

addition,encryptionshouldbeusedwheneversensitivedata,suchascreditcardorhealthinformationistransmitted.Applicationsthatfallbackorcanbeforcedoutofanencryptingmodecanbeabusedbyattackers.

ThePCIstandardrequiresthatallcreditcardinformationbeingtransmittedovertheinternetbeencrypted.


Allwebapplicationframeworksarevulnerabletoinsecurecommunications.

VULNERABILITY

Failuretoencryptsensitivecommunicationsmeansthatanattackerwhocansnifftrafficfromthenetworkwillbeabletoaccesstheconversation,includinganycredentialsorsensitiveinformationtransmitted.Considerthatdifferentnetworkswillbemoreorlesssusceptibletosniffing.However,itisimportanttorealizethateventuallya

hostwillbecompromisedonalmosteverynetwork,andattackerswillquicklyinstallasniffertocapturethecredentialsofothersystems.

UsingSSLforcommunicationswithendusersiscritical,astheyareverylikelytobeusinginsecurenetworkstoaccessapplications.BecauseHTTPincludesauthenticationcredentialsorasessiontokenwitheverysinglerequest,

allauthenticatedtrafficneedstogooverSSL,notjusttheactualloginrequest.

Encryptingcommunicationswithbackendserversisalsoimportant.Althoughthesenetworksarelikelytobemoresecure,theinformationandcredentialstheycarryismoresensitiveandmoreextensive.ThereforeusingSSLon

thebackendisquiteimportant.

Encryptingsensitivedata,suchascreditcardsandsocialsecuritynumbers,hasbecomeaprivacyandfinancialregulationformanyorganizations.NeglectingtouseSSLforconnectionshandlingsuchdatacreatesacompliance

risk.

VERIFYINGSECURITY

Thegoalistoverifythattheapplicationproperlyencryptsallauthenticatedandsensitivecommunications.

Automatedapproaches:VulnerabilityscanningtoolscanverifythatSSLisusedonthefrontend,andcanfindmanySSLrelatedflaws.However,thesetoolsdonothaveaccesstobackendconnectionsandcannotverifythattheyare

secure.Staticanalysistoolsmaybeabletohelpwithanalyzingsomecallstobackendsystems,butprobablywillnotunderstandthecustomlogicrequiredforalltypesofsystems.

Manualapproaches:TestingcanverifythatSSLisusedandfindmanySSLrelatedflawsonthefrontend,buttheautomatedapproachesareprobablymoreefficient.CodereviewisquiteefficientforverifyingtheproperuseofSSLforallbackendconnections.

OWASPTop102007

29

PROTECTION

ThemostimportantprotectionistouseSSLonanyauthenticatedconnectionorwheneversensitivedataisbeingtransmitted.ThereareanumberofdetailsinvolvedwithconfiguringSSLforwebapplicationsproperly,sounderstandingandanalyzingyourenvironmentisimportant.

UseSSLforallconnectionsthatareauthenticatedortransmittingsensitiveorvaluedata,suchas

credentials,creditcarddetails,healthandotherprivateinformation. Ensurethatcommunicationsbetweeninfrastructureelements,suchasbetweenwebserversand

databasesystemsareappropriatelyprotectedviatheuseoftransportlayersecurityorprotocollevelencryptionforcredentialsandintrinsicvaluedata.

IE7.0providesagreenbarforhightrustSSLcertificates,butthisisnotasuitablecontroltoprovesafeuseofcryptographyalone.Itjustmeansyoupaidalotmoreforacertificatethanmostfolks.

UnderPCIDataSecurityStandardrequirement4,youmustprotectcardholderdataintransit.PCIDSScomplianceismandatoryby2008formerchantsandanyoneelsedealingwithcreditcards.Ingeneral,

client,partner,staffandadministrativeonlineaccesstosystemsmustbeencryptedusingSSLorsimilar.Formoreinformation,pleaseseethePCIDSSGuidelinesandimplementcontrolsasnecessary.


http://cve.mitre.org/cgi‐bin/cvename.cgi?name=CVE‐2005‐4704 http://www.schneier.com/blog/archives/2005/10/scandinavian_at_1.html

REFERENCES

OWASPTestingGuide,TestingforSSL/TLS,https://www.owasp.org/index.php/Testing_for_SSL‐TLS

OWASPGuide,http://www.owasp.org/index.php/Guide_to_Cryptography

Foundstone‐SSLDigger,

http://www.foundstone.com/index.htm?subnav=services/navigation.htm&subcontent=/services/overview_s3i_des.htm

NIST,SP800‐52Guidelinesfortheselectionanduseoftransportlayersecurity(TLS)Implementations,http://csrc.nist.gov/publications/nistpubs/800‐52/SP800‐52.pdf

NISTSP800‐95Guidetosecurewebservices,http://csrc.nist.gov/publications/drafts.html#sp800‐95

30

A 1 0 – F A I L U RE TO R E S T R I C T U R L A C C E S S

Frequently,theonlyprotectionforaURListhatlinkstothatpagearenotpresentedtounauthorizedusers.However,amotivated,skilled,orjustplainluckyattackermaybeabletofindandaccessthesepages,invokefunctions,andviewdata.Securitybyobscurityisnotsufficienttoprotectsensitivefunctionsanddatainan

application.Accesscontrolchecksmustbeperformedbeforearequesttoasensitivefunctionisgrantedwhichensuretheuserisauthorizedtoaccessthatfunction.


AllwebapplicationframeworksarevulnerabletofailuretorestrictURLaccess.

VULNERABILITY

Theprimaryattackmethodforthisvulnerabilityiscalled"forcedbrowsing",whichencompassesguessinglinksandbruteforcetechniquestofindunprotectedpages.Applicationsfrequentlyallowaccesscontrolcodetoevolveandspreadthroughoutacodebase,resultinginacomplexmodelthatisdifficulttounderstandfordevelopersand

securityspecialistsalike.Thiscomplexitymakesitlikelythaterrorswilloccurandpageswillbemissed,leavingthemexposed.

Somecommonexamplesoftheseflawsinclude: "Hidden"or"special"URLs,renderedonlytoadministratorsorprivilegedusersinthepresentationlayer,

butaccessibletoallusersiftheyknowitexists,suchas/admin/adduser.phpor/approveTransfer.do.This

isparticularlyprevalentwithmenucode. Applicationsoftenallowaccessto"hidden"files,suchasstaticXMLorsystemgeneratedreports,trusting

securitythroughobscuritytohidethem. Codethatenforcesanaccesscontrolpolicybutisoutofdateorinsufficient.Forexample,imagine

/approveTransfer.dowasonceavailabletoallusers,butsinceSOXcontrolswerebroughtin,itisonlysupposedtobeavailabletoapprovers.Afixmighthavebeentonotpresentittounauthorizedusers,but

noaccesscontrolisactuallyenforcedwhenrequestingthatpage. Codethatevaluatesprivilegesontheclientbutnotontheserver,asinthisattackonMacWorld2007,

whichapproved"Platinum"passesworth$1700viaJavaScriptonthebrowserratherthanontheserver.

VERIFYINGSECURITY

ThegoalistoverifythataccesscontrolisenforcedconsistentlyinthepresentationlayerandthebusinesslogicforallURLsintheapplication.

Automatedapproaches:BothvulnerabilityscannersandstaticanalysistoolshavedifficultywithverifyingURL

accesscontrol,butfordifferentreasons.Vulnerabilityscannershavedifficultyguessinghiddenpagesanddeterminingwhichpagesshouldbeallowedforeachuser,whilestaticanalysisenginesstruggletoidentifycustom

accesscontrolsinthecodeandlinkthepresentationlayerwiththebusinesslogic.

Manualapproaches:Themostefficientandaccurateapproachistouseacombinationofcodereviewandsecuritytestingtoverifytheaccesscontrolmechanism.Ifthemechanismiscentralized,theverificationcanbequite

efficient.Ifthemechanismisdistributedacrossanentirecodebase,verificationcanbemoretime‐consuming.Ifthemechanismisenforcedexternally(WebSEALorSiteMinder),theconfigurationmustbeexaminedandtested.

OWASPTop102007

31

PROTECTION

TakingthetimetoplanauthorizationbycreatingamatrixtomaptherolesandfunctionsoftheapplicationisakeystepinachievingprotectionagainstunrestrictedURLaccess.WebapplicationsmustenforceaccesscontroloneveryURLandbusinessfunction.Itisnotsufficienttoputaccesscontrolintothepresentationlayerandleavethe

businesslogicunprotected.Itisalsonotsufficienttocheckonceduringtheprocesstoensuretheuserisauthorized,andthennotcheckagainonsubsequentsteps.Otherwise,anattackercansimplyskipthestepwhere

authorizationischecked,andforgetheparametervaluesnecessarytocontinueonatthenextstep.

EnablingURLaccesscontroltakessomecarefulplanning.Amongthemostimportantconsiderationsare:

Ensurethattheenforcementofyouraccesscontrolmatrixispartofthebusiness,architecture,anddesignoftheapplication.

EnsurethatallURLsandbusinessfunctionsareprotectedbyaneffectiveaccesscontrolmechanismthat

verifiestheuser’sroleandentitlementspriortoanyprocessingtakingplace.Makesurethisisdoneduringeverystepoftheway,notjustoncetowardsthebeginningofanymulti‐stepprocess.

Performapenetrationtestpriortodeploymentorcodedeliverytoensurethattheapplicationcannotbemisusedbyamotivatedskilledattacker.

DonotassumethatuserswillbeunawareofspecialorhiddenURLsorAPIs.Alwaysensurethat

administrativeandhighprivilegeactionsareprotected. Blockaccess toallfiletypesthatyourapplicationshouldneverserve.Ideally,thisfilterwouldfollowthe

"acceptknowngood"approachandonlyallowfiletypesthatyouintendtoserve,e.g.,.html,.pdf,.php.Thiswouldthenblockanyattemptstoaccesslogfiles,xmlfiles,etc.thatyouneverintendtoserve

directly.

SAMPLES



REFERENCES

OWASP,http://www.owasp.org/index.php/Testing_for_Directory_Traversal

OWASP,http://www.owasp.org/index.php/Forced_browsing

OWASP,http://www.owasp.org/index.php/Guide_to_Authorization

32

WH ER E T O GO F ROM H E RE

TheOWASPTop10isjustthebeginningofyourwebapplicationsecurityjourney.

Theworld'ssixbillionpeoplecanbedividedintotwogroups:groupone,whoknowwhyeverygoodsoftwarecompanyshipsproductswithknownbugs;andgrouptwo,whodon't.Thoseingroup1tendtoforgetwhatlifewaslikebeforeouryouthfuloptimismwasspoiledbyreality.Sometimesweencounterapersoningrouptwo…whoisshockedthatanysoftwarecompanywouldshipaproductbeforeeverylastbugisfixed.

EricSink,GuardianMay25,2006

Mostofyourusersandcustomersareingrouptwo.Howyoudealwiththisproblemisanopportunitytoimprove

yourcodeandthestateofwebapplicationsecurityingeneral.Billionsofdollarsarelosteveryyear,andmanymillionsofpeoplesufferidentitytheftandfraudduetothevulnerabilitiesdiscussedinthisdocument.

FORARCHITECTSANDDESIGNERS

Toproperlysecureyourapplications,youmustknowwhatyou’resecuring(assetclassification),knowthethreatsandrisksofinsecurity,andaddresstheseinastructuredway.Designinganynon‐trivialapplicationrequiresagood

doseofsecurity.

Ensurethatyouapply"justenough"securitybaseduponthreatriskmodelingandassetclassification

Askquestionsaboutbusinessrequirements,particularlymissingnon‐functionalrequirements

WorkthroughtheOWASPSecureSoftwareContractAnnexwithyourcustomer

Encouragesaferdesign–includedefenseindepthandsimplerconstructs

Ensurethatyouhaveconsideredconfidentiality,integrity,andavailability

Ensureyourdesignsareconsistentwithsecuritypolicyandstandards,suchasCOBITorPCIDSS1.1

FORDEVELOPERS

Manydevelopersalreadyhaveagoodhandleonwebapplicationsecuritybasics.Toensureeffectivemasteryofthewebapplicationsecuritydomainrequirespractice.Anyonecandestroy(i.e.performpenetrationtesting)–ittakesamastertobuildsecuresoftware.Aimtobecomeamaster.

ConsiderjoiningOWASPandattendinglocalchaptermeetings

Askforsecurecodetrainingifyouhaveatrainingbudget.Askforatrainingbudgetifyoudon’thaveone

Designyourfeaturessecurely–considerdefenseindepthandsimplicityindesign

Adoptcodingstandardswhichencouragesafercodeconstructs

Refactorexistingcodetousesaferconstructsinyourchosenplatform,suchasparameterizedqueries

OWASPTop102007

33

ReviewtheOWASPGuideandstartapplyingselectedcontrolstoyourcode.Unlikemostsecurityguides,itisdesignedtohelpyoubuildsecuresoftware,notbreakit

Testyourcodeforsecuritydefectsandmakethispartofyourunitandwebtestingregime Buyacopyof"TheSecurityDevelopmentLifecycle"(see[HOW1]inthebookreferences)andadoptmany

ofitspractices.

FOROPENSOURCEPROJECTS

Opensourceisaparticularchallengeforwebapplicationsecurity.Thereareliterallymillionsofopensourceprojects,fromonedeveloperpersonal"itches"throughtomajorprojectssuchasApache,Tomcat,andlargescalewebapplications,suchasPostNuke.

ConsiderjoiningOWASPandattendinglocalchaptermeetings

Ifyourprojecthasmorethan4developers,considermakingatleastonedeveloperasecurityperson

Designyourfeaturessecurely–considerdefenseindepthandsimplicityindesign

Adoptcodingstandardswhichencouragesafercodeconstructs

Adopttheresponsibledisclosurepolicytoensurethatsecuritydefectsarehandledproperly

Buyacopyof"TheSecurityDevelopmentLifecycle"andadoptmanyofitspractices.

FORAPPLICATIONOWNERS

Applicationownersincommercialsettingsareoftentimeandresourceconstrained.Applicationownersshould:

WorkthroughtheOWASPSecureSoftwareContractAnnexwiththesoftwareproducers

Ensurebusinessrequirementsincludenon‐functionalrequirements(NFRs)suchassecurityrequirements

Encouragedesignswhichincludesecurebydefaultfeatures,defenseindepthandsimplicityindesign

Employ(ortrain)developerswhohaveastrongsecuritybackground

Testforsecuritydefectsthroughouttheproject:design,build,test,anddeployment

Allowresources,budgetandtimeintheprojectplantoremediatesecurityissues

FORC‐LEVELEXECUTIVES

Yourorganizationmusthaveasecuredevelopmentlifecycle(SDLC)inplacethatsuitsyourorganization.AreasonableSDLCnotonlyincludestestingfortheTop10,itincludes:

Forofftheshelfsoftware,ensurepurchasingpoliciesandcontractsincludesecurityrequirements

Forcustomcode,adoptsecurecodingprinciplesinyourpoliciesandstandards

34

Trainyourdevelopersinsecurecodingtechniquesandensuretheykeeptheseskillsuptodate

Trainyourarchitects,designers,andbusinesspeopleinwebapplicationsecurityfundamentals

Adopttheresponsibledisclosurepolicytoensurethatsecuritydefectsarehandledproperly

OWASPTop102007

35

R E FE R EN CE S

OWASPPROJECTS

OWASPisthepremiersiteforwebapplicationsecurity.TheOWASPsitehostsmanyprojects,forums,blogs,presentations,tools,andpapers.OWASPhoststwomajorwebapplicationsecurityconferencesperyear,andhas

over80localchapters.

ThefollowingOWASPprojectsaremostlikelytobeuseful: OWASPGuidetoBuildingSecureWebApplications

OWASPTestingGuide OWASPCodeReviewProject(indevelopment)

OWASPPHPProject(indevelopment) OWASPJavaProject

OWASP.NETProject

BOOKS

[GAL1]GallagherT.,LandauerL.,JeffriesB.,"HuntingSecurityBugs",MicrosoftPress,ISBN073562187X

[HOW1]HowardM.,LipnerS.,"TheSecurityDevelopmentLifecycle",MicrosoftPress,ISBN0735622140

[HOW2]HowardM.,LeBlancD.,"WritingSecureCode",2nded.,MicrosoftPress,ISBN0735617228

[SCH1]SchneierB.,"PracticalCryptography",Wiley,ISBN047122894X

WEBSITES

OWASP,http://www.owasp.org

MITRE,CommonWeaknesses–VulnerabilityTrends,http://cwe.mitre.org/documents/vuln‐trends.html

SANSTop20,http://www.sans.org/top20/

PCISecurityStandardsCouncil,publishersofthePCIstandards,relevanttoallorganizationsprocessingorholdingcreditcarddata,https://www.pcisecuritystandards.org/

PCIDSSv1.1,https://www.pcisecuritystandards.org/pdfs/pci_dss_v1‐1.pdf

BuildSecurityIn,USCERT,https://buildsecurityin.us‐cert.gov/daisy/bsi/home.html

OWASP Web Security Guide

Documents

Transcript of OWASP Web Security Guide