Stealing passwrds via brwser refresh Authr: Karmendra Khli [karmendra.khli@paladin.net] Date: August 07, 2004 Versin: 1.1 The brwser s back and refresh features can be used t steal passwrds frm insecurely written applicatins. This paper discusses the prblem and the slutin. We will shw hw a bad guy can access the user credentials f the previusly lgged in user by expliting this feature, if the web applicatin has nt been develped securely Intrductin Brwsers have the ability t maintain a recent recrd f pages that were visited by a user. The back and frward buttn n brwsers use this functinality t display the pages recently brwsed. In additin brwsers als keep track f variables that were POSTed t the server while fetching the page. The refresh feature immensely increases the functinality f the brwsers and makes it cnvenient fr users. Mrever it is dne transparently s that users d nt need t be aware that the variables are autmatically psted t the server. All that a user has t d is t click n the yes buttn f a dialg bx prmpted by the brwser befre re-psting. This lets a user view the same pages that he had visited befre. Cnsidering functinality, this is a very pwerful feature but it can als be used t capture imprtant user credentials frm a brwser. Here the inherent feature f the brwser t stre POST variables is explited t gain access t imprtant user credentials. We will als be discussing anther variatin f the attack. These attacks are very simple t execute and require medium level f skills. Fr each variatin f the attack we have prpsed the slutin used t address the issue. 1
Capturing the lgin credentials f a user by refreshing the pst lgin page Let us cnsider a user making sme nline transactins n the Internet. 1. The user types in the URL f the site he wants t visit. In reply the page say lgin.asp is displayed. The web applicatin uses a username and passwrd as the user credentials. This page has frm fields Lgin ID and Passwrd, like what we have seen in many sites. 2. The user types his Lgin ID and passwrd and submits the request t the server. On the server authenticatin is dne by an ASP script, say Myhme.asp, that presents the user with the first page after lgin, say Myhme.asp. 3. The user brwses a number f intermediate pages n the site; say page2.asp, page3.asp, etc. 4. After the user has cmpleted his transactins and finished brwsing, he finally clicks n the Sign Out buttn. The lgut page, say lgut.asp, is invked which lgs ff the user. After the lgut.asp is displayed n the brwser, assume the user leaves the machine withut clsing the brwser windw. 5. If a bad guy has access t the same machine as the user, he can see that a lgut page is displayed n a brwser windw. 6. He clicks n the back buttn drp dwn list and identifies the page immediately after lgin here Myhme.asp. He clicks n the drp dwn list crrespnding t the Myhme.asp page and is displayed the Warning: Page has Expired errr page that we have seen many a times. 2
7. At this pint the bad guy starts a brwser prxy 1 and cnfigures the brwser t g thrugh the prxy. 8. On the errr page he clicks the refresh buttn. A pp up warns the user that sme f the variables are t be repsted in rder fr the page t be displayed and asks the user if he wants t cntinue r nt. The bad guy clicks yes. 1 A brwser prxy is a tl that can capture the data flwing between a brwser and web server. The brwser s prxy settings have t be set t use the prxy. Achilles brwser prxy was used during ur tests. 3
9. The bad guy views the request sent frm the brwser t the server in a brwser prxy. He is able t see the username and passwrd f the user. He nw has cmplete knwledge f user credentials and hence cmplete cntrl ver the accunt. 4
Cause f the prblem What happens is that each brwser instance remembers all pages that it had displayed t the user. In additin t this it als keeps track f all requests that were sent t the server fr fetching a particular page. In ur case the Myhme.asp was displayed nly after the user had entered his Lgin ID and Passwrd. S the brwser in additin t remembering that at sme mment f time it had served Myhme.asp t the user als remembers the request that was sent fr fetching the Myhme.asp which cntains the Lgin ID and Passwrd the user had prvided n the lgin.asp page. Nw when the bad guy clicks the refresh buttn n Myhme.asp, the request that had been used t render the Myhme.asp page is resent t the server. This request cntains the Lgin ID and Passwrd credentials which the bad guy can intercept. Slutin We have listed dwn tw slutins that can be used t slve the abve issue. Intrduce an intermediate page t carry ut the authenticatin r use the salted hash technique t pst the passwrds t the server. 1. The recmmended slutin is t intrduce an intermediate page, say Authenticatin.asp, which perfrms the authenticatin checks. T understand hw that slves the prblem, let s first lk mre clsely at what had happened during lgin. User types URL www.site.cm User gets lgin.asp User submits Lgin credentials which are send t Myhme.asp User is authenticated by Myhme.asp and is displayed Myhme.asp 5
The fllwing figure dentes the abve steps: GET www.website.cm/ lgin.asp www.website.cm/lgin.asp lgin.asp POST Lgin ID+Passwrd Myhme.asp www.website.cm/myhme.asp Nw, cnsider that an intermediate page has been intrduced. The steps perfrmed are: User types URL www.site.cm User gets lgin.asp User types Lgin credentials and submits which are sent t Authenticatin.asp User is authenticated by Authenticatin.asp. The Authenticatin.asp then redirects the user t Myhme.asp. In this case the user submits the Lgin ID and passwrd t Authenticatin.asp. Here the Authenticatin.asp was never displayed n the brwser, hence there is n pssibility f the bad guy using the back buttn t reach the Authenticatin.asp page. If the bad guy des a refresh n Myhme.asp page, the request which the brwser used t render 6
Myhme.asp is sent. This request is nthing but a redirect request sent by Authenticatin.asp. Here an imprtant nte is that the redirectin request must cntain the sessin ID assigned t the user after authenticatin. The fllwing figure explains the slutin described abve: GET www.website.cm www.website.cm/lgin.asp lgin.asp lgin.asp POST Lgin ID+Passwrd Redirect t www.website.cm/myhme.asp Authenticatin. asp Redirect request GET www.website.cm/myhme.asp www.website.cm/myhme.asp Myhme.asp 2. A secnd slutin is t use a salted hash technique fr authenticatin. A discussin n salted hash is utside the scpe f this paper; the AppSec FAQ at OWASP has an excellent write-up n salted hash technique. 2 2 http://www.wasp.rg/dcumentatin/appsecfaq 7
Variatins f the attack Capturing user credentials by refreshing an intermediate page The abve attack als wrks fr any intermediate page n the applicatin where imprtant user credentials are POST-ed t the server. An example is the passwrd change page. While brwsing the site if the user had visited the change passwrd page then the variables psted by him typically the ld passwrd and the newly chsen passwrd - are stred by the brwser. If a refresh is dne n this page then the request cntaining these passwrds is sent t the server and can be viewed using a brwser prxy tl. Slutin 1. The slutin is same as discussed earlier. Here t we have t intrduce an intermediate page. The passwrd change request shuld be accepted and prcessed by this intermediate page. The result f the passwrd change is then displayed t the user by redirectin t the next page. Capturing lgin credentials when the applicatin uses frames We discuss a variatin f the attack when a site uses frames. Let us cnsider that in the abve example, Myhme.asp cnsists f tw frames. The frame n the tp cnsists f links t ther applicatins and the bttm frame is used t display the results f a request. The frame n tp, after getting rendered frm the server the first time, remains cnstant and is nt changed while brwsing frm ne page t anther. The bttm frame changes fr each request. As the tp frame remains cnstant, a refresh n ANY page will resend the request cntaining the user credentials. Here what happens during a refresh is that bth the frames are individually refreshed. The frame n tp refreshes and sends the request that was used t render itself. This was the first request frm lgin.asp cntaining the username and passwrd. Hence it cntains the user credentials. The bttm frame refreshes and sends the request generated by its previus page. S we can view the username and passwrd by using a brwser prxy. 8
Slutin 1. The slutin fr this, as discussed abve, is t display the Myhme.asp by redirecting thrugh an intermediate Authenticatin.asp. 2. Anther slutin as described abve is t use the salted hash technique fr authenticatin. Cnclusin We have seen hw simple it is t steal user credentials by using the brwser s back and refresh features if a web applicatin has nt been develped securely. By implementing the slutins mentined, we can safeguard the user s credentials frm unauthrized access. References: Applicatin Security FAQ at Open Web Applicatin Security prject URL: http://www.wasp.rg/dcumentatin/faq.html SecurityFcus HOME Mailing List: Web Applicatin Security URL: http://www.securityfcus.cm/archive/107 9