View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005065 | OXID eShop (all versions) | 4.02. Session handling | public | 2013-04-12 12:03 | 2013-04-16 17:14 |
| Reporter | henrik.steffen | Assigned To | |||
| Priority | high | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | no change required | ||
| Platform | MSIE9 | OS | Windows | OS Version | all |
| Product Version | 4.6.0 revision 44406 | ||||
| Summary | 0005065: Session is detected as swapped after payment on external website (Ogone/iDEAL) because of UserAgent change | ||||
| Description | In an oxid enterprise shop we have encountered the problem, that some users (< 5%) are not getting to the thankyou page, even though everything with order and payment went fine. After debugging this for a couple of days, we've found out, that the reason is the implementation of some involved bank companies (especially the Rabobank in the Netherlands) where the browser compatibily mode is set to MSIE7. After completing the transaction the user is getting redirected back to the shop, and in this redirect the UserAgent has been switched from MSIE9 to MSIE7. I noticed a quite similar bug, which was solved earlier: https://bugs.oxid-esales.com/view.php?id=1950 However, this doesn't go far enough, because if you compare the different UserAgents here, it's not only the indicated MSIE-version, but even the rest of the User-Agent-string: Before payment: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0) After payment: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/5.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C) The _checkUserAgent() delivers "true", so the session is detected as _isSwappedClient() == true ! This empties the basket, logs off the user and redirects to startpage of the shop. Comparison of UserAgents is not really a way to make a session more secure... an attacker who knows the session-id can easily obtain the UserAgent, too. So what's the deal of having a UserAgent check anyway? At least (as desired by different other users in oxid forum and mantis) the UserAgent check should be configurable to on or off. Or maybe at least a by-pass for the thankyou page? What I've done now as a workaround is to modify the _checkUserAgent() by: if (oxConfig::getParameter('cl') == 'thankyou') { $blCheck = false; } | ||||
| Steps To Reproduce | You need a rabobank account to test an iDEAL payment with ogone. But you can easily imagine, what happens, if suddenly the UserAgent string changes when the thankyou page is accessed, can't you? The same problem could also affect other external payment mechanisms, such as the paypal problem which was solved earlier. | ||||
| Tags | No tags attached. | ||||
| Theme | Both | ||||
| Browser | All | ||||
| PHP Version | any | ||||
| Database Version | any | ||||
|
|
When redirecting to Rabobank in URL should be added "rtoken" parameter: $oSession = new oxSession(); "&rtoken=". $oSession->getRemoteAccessToken(); This will generate new access token and when client will be redirected from Rabobank to e-shop this token will be compared and user agent check will be skipped. |
