Tải bản đầy đủ - 0 (trang)
Chapter 12. The Web and Security

Chapter 12. The Web and Security

Tải bản đầy đủ - 0trang

12.TheWebandSecurity

Withanyluck,wetwocoauthorsarestillinthefirsthalvesof

ourlives.Asrelativeyoungsters,it'sstrangetobeabletostart

talkinglikeanold-timer.Butold-timersweare,forwecan

remembertheDarkAgesbeforetherewasaWeb.

Yes,Virginia,therewassuchatime.Publicnetworked

interactiontookplaceonsuchthingsasUSENETnewsgroups

(allASCIItext).Indeed,thereoncewasn'tevenan"Internet";

andemailviaBITNETandUUNETrequiredknowingnotonly

yourcolleague'semailaddressbutalsotheroutebywhicha

messagecouldgetfromyoursitetoyourcolleague'ssite.

However,thankstolazyphysicistsinSwitzerland,wenowhave

theWorldWideWeb.Wecouldspendquiteabitoftimeonthis

topic;itseemsthateverytimewetrytonaildownsome

specificbehaviororissue,wediscoverafewmorewrinkles.

Indeed,theWeboffersamicrocosmofsecurity'soverarching

issues.Weseeacontinualchurnofevolvingstandards,code,

andpractices—oneofthereasonsit'shardtonaildowndetails.

Weseecodethatdoesn'talwayswork,includingdifferent

versionsofthesamebrowserthatdonotworkthesameway.

Weseeanotionof"correctness"thatisveryhardtopindown.

Weseeahistoryofimplementationblunders.Andwealsoseea

technologythatnonethelesshasbecomecentraltotheway

modernsocietyoperates.

DiscussingtheWebusesmanyoftheelementswe'vetalked

aboutsofar.Weneedtotalkabout"correctness"(Chapter1),

networks(Chapter5),implementationblunders(Chapter6),

cryptography(Chapter7),authentication(Chapter9),andPKI

(Chapter10).Thismaterialalsorelatestotopicswedealwith

later:policyandmodels(Chapter15),securehardware

(Chapter16),andhumanbehavior(Chapter18).

Section12.1goesthroughthebigpicturetorefreshthe

piecesofthebasicstructure.



Section12.2discussesstandardsecuritytechniquesforWeb

interaction.

Section12.3focusesonsomeoftheprivacyimplications.

Section12.4quicklyreviewstheemergingareaofWeb

services.

However,theWebisarapidlyevolvingfieldwherestandards

seemtoberegardedasevenmoreoptionalandflexiblethanis

normal.Consequently,weneedtoraiseabig,visiblecaveat

here:Althoughtheissueswediscussarecurrentatthetimeof

thiswriting,oneneverknowswhatthefuturewillbring.



12.1.BasicStructure

12.1.1.BasicAction

Reasoningaboutthesecurityandprivacyissuesinvolvedina

process,suchasWebinteractions,requiresstartingwitha

mentalmodeloftheprocess.Sincehumansseemtolike

buildingmentalmodelsfromwhattheyexperience,andsince

everyreaderhasprobablyexperiencedusingtheWeb,westart

withthemodelthatexperiencesuggests.

Let'ssupposethatuserAliceisvisitingaWebpageatBob's

site.Atfirstglance,wehavetheseelements:

AliceandBob

Alice'smachine,runningaWebbrowser

Bob'smachine,runningsometypeofWebserver

Bob'swebpageP.

Wethenhavethisaction:

AlicepointingherbrowsertoBob'ssite

Bob'sserversendingbackthepageP



Alice'sbrowserdisplayingP

However,realityismorecomplexthanthissimplemodel,and

thisiswherethefuncomesin.TheWebhasbecomethe

primaryportalforallsortsofinformationandservicedelivery.

Asaconsequence,stakeholdersofalltypesneedtomake

rationaldecisionsaboutsecurityandprivacyimplicationsof

theiractionsinthismedium.Thesestakeholdersrangefrom

ordinary(orevensavvy)users,toindividualssettingupWeb

pages,toenterprisescontemplatingWebservers—tolegislators,

lawyers,andinsurersmakingpolicydecisionsaboutresponsible

andnegligentbehaviorinthisrealm.Whenauser'smental

modelomitscrucialcomplexity,thatusermaymakeimportant

decisions(withimportantreal-worldramifications)basedona

pretendviewofthesituation.Suchmistakesmaybesignificant.

Wethususethismismatchasasteppingstonetoexploring

Websecurityissues.



12.1.2.ThePageRequest

TheBrowser'sRequest

WemightstartbythinkingaboutAlice'srequest:theuniform

resourcelocator(URL)thatshemighthavetypedintothe

locationbar.Consider:

http://www.cs.dartmouth.edu/~sws/

Thehttpindicatesthatitisthenetworkprotocoltobeused.

WethinkoftheWebassynonymouswiththeHypertext

TransportProtocol(http).Infact,thisidentificationisoften

implicit:Websitessometimesomittheprotocolpartwhen

advertisingURLs;Webbrowsersoftenfillinthehttp

protocolbydefault,ifaprotocolpartisn'tspecified.

However,browsersoftenalsohappilyspeakothernetwork

protocols,suchasftpandtelnet,aswellashttps,whichwe

discusslater.Theprotocolissueisfurthercomplicatedby

thefactthatmanybrowserswillalsoactasaportalinto



Alice'sownfilesystem;soaprotocolname,suchas"file",

mightsendthebrowsernotintooutercyberspacebut

ratherintoAlice'sownmachine.

Thehostname"www.cs.dartmouth.edu"indicatesthe

externalWebsiteatwhichthepagelives.Bobwillhave

configuredtheserversoftwareatthismachinetolook

withinsomespecialdirectorythereforWebmaterial.

Thepath"~sws"indicateswherethematerialAlicewants

liveswithinthisdirectoryatBob'smachine.Inthiscase,in

standardfilesystemsemantics,Bob'smachinewilllookin

thehomedirectoryofusersws,withinadirectorycalled

public_html.(Weshouldpointoutthatthedirectorymay

notalwaysbeonBob'sphysicalmachine;thingslikefailure

andloadbalancingmaymovethematerialtodifferent

machines,eventhoughtheaddressdoesn'tchange.)Ifthe

URLspecifiesadirectoryratherthanafilename,theserver

willdefaulttolookingforawell-definedindexfile,suchas

index.html;ifnoindexfilecanbefound,theservermay,

dependingonitsconfiguration,provideinsteadalistingof

thedirectory.

Ofcourse,thisbehaviordoesnotfollowfromthelawsof

naturebutratherfromtraditionmixedupwithvarious

standards.Theserversoftwarecaninfactdowhateverit

wantsto,andBobmayhaveseveralstandardconfiguration

options,suchasredirectingrequestsforcertainURLsto

otherplaces.

Ofcourse,thiscomplexitymayhavesecurityramifications.

WhatserverisAlice'smachineworkingwith,really?What

fileatBob'smachineisbeingshown?



Alice'sRequest

IntheprecedingdiscussionofURLs,wecasuallyobservedthat

AlicemayhavetypedtheURLintoherbrowser.Atonepoint,

perhaps,thatmighthavebeenthedominantwayusersbegan



theirWebexploration.However,thedominantwaytodayhas

gonethroughseverallevelsofchanges.

Alicecuts-and-pastesratherthantypestheURLintoher

browser.(Isshepayingasmuchattentiontothedetailsfor

theURL?)

Alicesimplyclicksonalinkfromanotherpage.Sometimes,

ifshemousesoverthelinkwithoutclicking,theURLmay

appearonthestatusbaratthebottomofthebrowser.Is

shepayingattention?

Alicesimplyclicksonalinkinsideanemail,PDFfile,or

someothercontentthatdoesnotevenexplicitlyappearto

beWebcontent.

Thesesubtletiesaresignificantbecausethefirstlevelofaccess

controlandauthenticationoccurinsideAlice'shead,basedon

herperceptionofwhatsiteshe'svisiting.Evenifsheseesthe

URL,it'snotclearthatAlicewillmakethecorrectdecision.

(Indeed,phishingattacksexistpreciselybecauseenoughusers

donotmakegooddecisionsabouttheURLstheirclicksinvoke.)

Inthehierarchicalwaythathostnamesaredecided,an

organizationthatcontrolsanamemaysetuphostswith

essentiallyarbitraryprefixesaddedtothatname.For

example,intheory,nothingstopsdartmouth.edufrom

settingupahostname

www.trustworthy.bank.com.dartmouth.edu.

Wouldcustomersof

www.trustworthy.bank

noticethedifference?Foranotherinterestingexample,an

enterpriserecentlyregisteredthehostnameandsetupan

automatedsystemsothatrequeststoURLswiththesuffix



name.edu.com

camebackwithWebcontentthatappearedtorepresentthe

university"name."(Universitieswerenothappy.)

Thetendencyofsomebrowserstohelpfullyexpand

incompleteURLsintowhattheythinktheuserintendedcan

alsocausetheusertoendupsomewhereotherthanwhere

sheintended.Werecallaclassroomdemonstrationinwhich

typinginthepartialURL"whitehouse"causedthebrowser

togonotto"www.whitehouse.gov,"thesiteoftheU.S.

president'sresidence,butto"www.whitehouse.com,"which

wasatthattimeapornographicsite.

Typejackingisanotheroldapproachtosubvertingthe

user'sperceptionofwhereheorsheisgoing.Here,the

adversaryusescreativetypographytopickadomainname

thatappearsdeceptivelysimilartotheintendedone.Oneof

thefirstwell-knowncaseswas"paypai.com,"which,when

renderedlowercaseinstandardfonts,looksanawfullotlike

"paypal.com."Onesuspectsthat"paypa1.com"—

substitutinganumeralforthelowercasel—mightalsowork.

Inrecentyears,Unicodeencodingofcharactershasbegun

supplantingASCII,inordertoaccommodatethemuch

largersetsoffontsrequiredforinternationalization.

Researchershavespeculatedonthepotentialfor

typejackingusingsimilar-lookingcharactersfromfonts

otherthanthestandardRomanonesthatWesternusers

expect.

Webstandardsalsopermituserstospecifyausernameand

passwordaswellasthehostname:

"username:password@hostname."Thisfeaturecanalsobe

usedtodeceiveusers:forexample,theadversarycan

providealinkwithaURLwherethe"username"component

itselflooksliketheintendedURLandtheremaining

componentsareobscured.SomeversionsofIEevenhadan

escapesequencebug(recallSection6.2.4)that,iftheURL



hadthecorrectescapecharactersbeforethe"@,"the

browserwouldnotevendisplaythe"@"andwhatcame

after,thusleavingtheusertomakeatrustjudgmentbased

onlyonthefakepartoftheURL[Int04].

Eveniftheuserisperceptiveenoughnottobefooledby

deceptiveURLtricks,theadversarycandoanendrun

aroundthiswisdom.Webpagescanconsistofmorethan

simplypassivecontent,aswediscussinSection12.1.3.

Somespoofingsiteshavepackagedlinkswithevent

handlersformouseevents,inordertotellthebrowserto

renderafakeURLonthestatusbarwhentheusermoves

themouseoverthelink.

Chapter18considersfurthertheseissuesofhowhumansmake

trustjudgmentsbasedonuserinterfaces.



Interaction

Inhermind,Alicemaybedoingmorethansimplyrequesting

pagesfromBob'sserver;shemaybetryingtofilloutaformor

otherwiseinteractwiththeWebcontent.HTMLprovidesa

standardsetoftoolsforthis.TheWebpagecodecaninclude

formelements.AformelementincludesaURLtowhichthe

forminformationshouldbesentwhensubmitted,amethodby

whichtosubmitit,aswellasinputelements.Theseinput

elementscreatesuchthingsasradiobuttonstoclick,boxesto

typetextinto,andevenwaysforausertonameafileto

upload.Eachinputelementcanspecifyanameofthe

parameteritcollects.Fillingouttheinputattachesavalueto

thisparameter.Sometimes,theinputcodecanevenincludea

defaultvaluetouse,iftheuserprovidesnone;the

specificationsalsoallowforhiddeninputfieldsthatprovidea

defaultvaluewithoutlettingtheuserknowaboutit.

Whentheformissubmitted,Alice'sbrowsersendsarequestto

theURLthattheformelementspecifiedinitsactionfield.Her

browseralsosendsbackalltheparameterinformation



associatedwiththeinputelementsforthatform.However,how

herbrowsersendstheseparametersdependsonthemethodof

theform:

IfthepagedoesitviaGET,theanswerstothequestionsare

appendedtotheURLsentback.

IfthepagedoesitviaPOST,theanswerstothequestions

aresentbackseparately.

(HowaWebformworksmightbeconsideredabitarcanefor

theaverageuser.However,thequestionofwhetheraURLwill

containtheuser'sprivateresponsescertainlyisnot!)

Typically,theserverontheotherendofthisURLwillbe

configuredtograbtheseparametersandrespondsomehow.

UsuallythisisdonebytheURL'sspecifyingaCGIscript

(althoughitcouldbeanyotherkindofexecutable),whichturns

aroundandspitsoutHTMLcodetosendback,perhapsafter

interactingfirstwithsomeback-endservicecode.



WebFormProcessing

Alice'sinteractionwiththeWebformmayinvolveproviding

sensitiveinformation,suchasherincomeorprescription

information.Consequently,itisimportanttounderstandwhat

happenstotheinformationshe'sprovidedtotheWebpagein

frontofher.

Thisinformationisgoingofftotheserverattheotherend

oftheactionURL.

Unlesscountermeasuresaretakentoencryptthechannel,

theentiresetofquestionsandanswerswillbesentin

plaintextoverthenetwork.Thisdatawillthusbevisibleto

—andchangeableby—anynetwork-leveladversary.

IftheparametersaresentbackviaGET,theyformally

becomepartoftheURLthebrowserrequests.Thismeans



thattheywillperhapsbevisibleinWeblogsandhistory

lists,aswellasinthelocationbarofthebrowser.Aspartof

theURLoftheowningpage,theinformationmayevenbe

passedontothirdparties;seeSections12.1.4and12.3.3.

Unfortunately,evenifAliceistrainedtoexaminethetargetURL

thatappearsonthestatusbarwhenshemousesoveralink,

thereisgenerallynoeasywayforhertodeterminetheaction

URLofaformorwhethertheparameterswillbesentviaGETor

POST.



Cross-SiteScripting

Server-sideCGIscriptshavebeenacommonmediumfor

escapesequenceattacksovertheyears.Anotherfamilyofevilinputattackiscross-sitescripting(XSS),bywhichaserver

injectscodethatappearstobefromadifferentserver.This

approachisabittricky,sowe'llwalkthroughsomeexamples.

AliceisaWebuser.

Bobisaserveroperator.

AlicetrustsBob.Unfortunately,Bobisnottrustworthy;

althoughheisnotmalicious,he'snotasvigilantashe

shouldbeabouthowhisinteractivepageshandle

unexpectedclientinput.

CarlohassomemaliciousWebmaterialM.Hewouldliketo

haveAlicerenderthismaterialinherbrowser.However,

Alice,wisely,doesnottrustCarlo.

Incross-sitescripting,CarloexploitsBob'scarelessnessby

embeddingthemaliciouscontentMwithinapageofferedby

Bob,oratleasttomakeitappearthatway.ThisenablesCarlo

toachievehisgoal:Alicewillacceptthiscontentbecauseit

comesfromBob,andshetrustshim.HowdoesCarlodothis?

Weoffertwocommonscenarios:



Bob'ssitemightofferabloggingcapabilitythatletsthirdpartyusersuploadcontentbutdoesnotsufficientlyscreen

thiscontentforescapesequencesandotherissues.Carlo

entersMaspartofanentry.

BobmayhavesetupasitethatletsAliceaskfor

complicatedthingsviaaURL;maybeAlicegeneratesa

complicatedrequestbasedonaformresponseandGET.

However,Bob'scodefailstoallowforbizarrelycrafted

input.

CarlocreatessuchaninputandofferstoAlice—forexample,

embeddedinphishingemail.Sheclicksonit,becauseitgoesto

Bob—butcausesBob'ssitetogetAlice'sbrowsertorunthe

maliciousM.

Asareal-lifeexampleofthelatter,wereceivedsomeeBay

phishingemailthatintendedtoharvesttherecipient'seBay

useridandpasswordbyofferingthislonglink:

http://signin.ebay.com/ws/eBayISAPI.dll?

SignInMCAlert&

ru=http://client-66-116-24-226.consolidated.net:82

/signin.ebay.com/reg.php



Itlookssafe,sinceitgoestoeBay.However,what'sthisru=

stuffallabout?(Itappearstoredirecttheusertothissecond

URL,onsuccessfulloginateBay.Wespeculatedthatthis

secondsitemayclaimthatloginfailedandofferaspoofofthe

eBayloginpage.)



12.1.3.PageContent

Inthebasicmodel,theuserAlicepointsherbrowser(viatyping

orclicking)toBob'ssite,thepagePcomesback,andAlice's

browserrendersit.Realitydiffersinmanyaspects.



Alice'sBrowser

Tostartwith,thisbasicmodelmightleadonetoconcludethat

"renderingapage"isawell-definedactionthatallbrowsersdo

thesameway.AsmanyconscientiousWebsitedesignershave

discovered,thisisnotthecase.Differentbrowsersact

differentlyoncontent;wehaveevennoticedthatthesame

browser,ondifferentOSplatforms,actsdifferently.

Anotherfallacywiththismodelisthattherenderingisdone

entirelybyAlice'sbrowser.Althoughstandardhtmlcontent

probablyis,manyothertypesofcontentmaygetsenttoother

applicationsonAlice'smachine;forexample,PDFdocuments

maygetsenttoAdobeAcrobat.Sometimes,thisreroutingof

contenttoaparticularhandlerisveryexplicitand"transparent"

totheuser.

Alicemayseetheseparateapplicationgetinvokedandthus

knowthatthisseparateapplicationisinvolved.

SomebrowsersmayevenmakeitveryeasyforAliceto

configurewhatapplicationprogramsshouldbeinvokedfor

whattypeofcontent.

Unfortunately,thisreroutingmoreoftensimplyhappenswithout

theuser'sawareness(anotherversionof"transparent").

Therenderingviaaseparateapplicationmayoccurwithin

Alice'sbrowser'swindow,leadingtoanimpressionthatthis

ispartofthebrowseritself.

Onsomeplatforms,howtoconfigureoreveninvestigate

howthebrowsermapscontenttypestoseparate

applicationsmayberatherelusivefortheordinaryoreven

savvyuser.

Fromasoftwareengineeringperspective,invokingaseparate

applicationcanmakesense.Whyabsorbthefullsourcefora

complicatedtaskwithinthebrowserwhenwecanpluginthe



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Chapter 12. The Web and Security

Tải bản đầy đủ ngay(0 tr)

×