View Issue Details

IDProjectCategoryView StatusLast Update
0005065OXID eShop (all versions)4.02. Session handlingpublic2013-04-16 17:14
Reporterhenrik.steffen 
PriorityhighSeveritymajorReproducibilityalways
Status resolvedResolutionno change required 
PlatformMSIE9OSWindowsOS Versionall
Product Version4.6.0 revision 44406 
Target VersionFixed in Version 
Summary0005065: 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 ReproduceYou 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.

TagsNo tags attached.
ThemeBoth
BrowserAll
PHP Versionany
MySQL Versionany

Activities

mantas.vaitkunas

2013-04-16 17:14

administrator   ~0008617

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.