how does url hashing security work in wln?

Benjamin Anderson
Benjamin Anderson
in TR Internal
For the Inline KeyCite Flags feature project, we're adding a parameter onto requests to the FullText endpoint of Document to indicate whether or not the user has purchased the feature (which is an ancillary charge). This leaves all the billing logic in the Website module. However, we noticed that for chunked docs, subsequent chunk requests go straight from the browser to the Document module. I navigated to this document (125 S.Ct. 738 - U.S. v. Booker) in my browser and observed the following request in fiddler (using the normal forward proxy mode) for a subsequent chunk: >
http://1.next.ci.westlaw.com/Document/v1/FullText/I3a84f1d79c9d11d991d0cc6b54f12d4d?clientId=ANDERSONBD1&chunkNumber=1&contextData=(sc.History*oc.UserEnteredCitation)&originalContext=UserEnteredCitation&originationContext=clientid&cacheScope=bce903a9a621049fb7de37a890ca3368 I then took that fiddler request, slightly modified it by adding a parameter to the end, and reissued it in fiddler: >
http://1.next.ci.westlaw.com/Document/v1/FullText/I3a84f1d79c9d11d991d0cc6b54f12d4d?clientId=ANDERSONBD1&chunkNumber=1&contextData=(sc.History*oc.UserEnteredCitation)&originalContext=UserEnteredCitation&originationContext=clientid&cacheScope=bce903a9a621049fb7de37a890ca3368**&inlineKeyCiteFlags=true** > > response 200 - success (includes > Inline KeyCite flags) I then took the original request and changed the guid to Roe v Wade and reissued it in fiddler: >
http://1.next.ci.westlaw.com/Document/v1/FullText/**I32a9810a9c2611d993e6d35cc61aab4a**?clientId=ANDERSONBD1&chunkNumber=1&contextData=(sc.History*oc.UserEnteredCitation)&originalContext=UserEnteredCitation&originationContext=clientid&cacheScope=bce903a9a621049fb7de37a890ca3368 > > response 403 - forbidden What I'd like to be able to do is to make the second request above (for inline keycites) also return a 403. My guess, based on the very limited knowledge I have of what's going on, is that the guid is included in generating a hash that is then validated against the url to verify it hasn't been tinkered with. I'm guessing our new parameter (inlineKeyCiteFlags=true) is not included in that hash generation. Does anyone happen to know how/where that hash is generated? All of the above requests use the same headers (below). I'm wondering if either the x-cobalt-pcid or the x-cobalt-rtid below is the hash consisting of certain parts of the url? x-cobalt-documentContentCacheKey: WestlawNext|I3a84f1d79c9d11d991d0cc6b54f12d4d|||||||||0|False|{"HighlightPoints":null,"HighlightTerms":null,"SecondaryHighlightTerms":null}|False|||False|False|||True|L|False|Core|0| x-cobalt-exectype: async x-cobalt-pcid: 7f82b288ed5f410f85b23e67ea616ffa x-cobalt-rtid: v1|47d85c13faeb49824a9be774dbe3d7e0c9804765232acb3eafd4b2df3859f8e9 x-cobalt-host:
document.int.next.ci.westlaw.com Accept: text/html, */*; q=0.01 X-Requested-With: XMLHttpRequest Referer:
http://1.next.ci.westlaw.com/Document/I3a84f1d79c9d11d991d0cc6b54f12d4d/View/FullText.html?listSource=Foldering&originationContext=clientid&transitionType=MyResearchHistoryItem&contextData=%28oc.UserEnteredCitation%29&VR=3.0&RS=cblt1.0 Accept-Language: en-US Accept-Encoding: gzip, deflate User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0) Connection: Keep-Alive DNT: 1 Host:
1.next.ci.westlaw.com Cookie: Web_SessionId=az5ykzf1awrzh0gk5pf13acg; site=b; ig=ci_b_1; web_pm=10.220.24.37_9001; bhCookieSess=1; bhCookiePerm=1; bhResults=bhfx=11%2C7%2C700%2C224&bhfv=11&bhsh=1050&bhsw=1680; SessionStorage=%7B%22ReadingModeView%22%3A%22regular%22%2C%22IsSkipOutOfPlanChecked%22%3Afalse%2C%22Created%22%3A%2207/17/2013%2020%3A08%3A05%22%2C%22Client%22%3A%22ANDERSONBD1%22%2C%22ActiveReqs%22%3A6%2C%22ReqWindow%22%3A8%7D; Co_SessionToken=s8pL8HOCA-63C5Vp9i6yKSiA5HW-p7HR4p7GaoPoRYPqAf_-iTgw9htj32dnpEY8SHNDtp3-rJrV_m9wjdEj3hFBerM4yNe9SWlCN0VF9yiX0imFUSzqUMhqNZyiPJnF; RememberMe=%7B%22user%22%3A%22andersonbd1%22%2C%22pw%22%3A%22%25Au/oPm7PfEO-%22%7D; fol_pm=10.204.32.189_9001; BIGipServerci_apache_b=489282570.10787.0000; MUD=product=www
Tagged:

Best Answer

  • kevin.hakanson
    kevin.hakanson
    Answer ✓
    Take a look at the Resource Authorization section of [Apache Cobalt Module Documentation][1] > Hash key (sessionId,page guid,resourceId) using SHA256 algorithm and compare it to the x-cobalt-rtid header. Do a view source on your document page, and you see the `x-cobalt-rtid` header is valued by the `Cobalt.Website.Events.ResourceToken` JavaScript variable.
    The "guid" that is used in the has computation is the capture group specific in the regex mentioned in the Apache documentation. The original concept is one billable check per page context (hence the one capture group) so you don't "buy" one document and the view another. [1]:
    http://tfsnpt.int.thomson.com/Sites/Cobalt%20Infrastructure/teamwiki/Wiki%20Pages/Apache%20Cobalt%20Module%20Documentation.aspx

Answers

Categories