IOS: Different Hash for SEBConfigKey than in Windows?

[beursken]

Describe the bug
I am using an SEB-File created using the Windows Configuration Tool (latest version).

Running that SEB file on a Windows Client and using the Javascript API (i.e. SafeExamBrowser.security.configKey) returns a key which properly validates to a hash of URL+ConfigKey on the server side.

However, using the same file to access the same URL on iOS produces a different ConfigKey.

There was a similar bug-report (#421) in 2024 which could not be reproduced and was therefore closed. #309 refers to a completely different issue (the server side application does not validate iframes)

To Reproduce

I am using the attached SEB-file (as an example).

Klausur 06-01-2026-09-19.zip

I have used the Admin-Password
asd7623M658.JKUILNeuweoutirARDfzhjedrfskiuzchHZUIvbnkdjhf,vnb
and Quit-Password
quit
for this example

On Windows this results in the Hash
09dfeb15c9a9a51cec7010b67bf2b4a6d53e1cfe10b2b384dc45f6503ed20798 which is identical to the Hash I get when using ComputeSha256Hash(URL + myConfigKey)

On iOS I (consistently) get
b84aea16b23f26856d461cac2b43fac6298e8bade3f588d29dc4b2b32e60dba5
which is evidently different.

The iOS-log-file is inconclusive
SEB-iOS-Client.log

Expected behavior
Both platforms should result in identical Hash-values for identical URLs when using identical SEB-files.
I assume the reason is either

a. that iOS for some reason encodes a different URL (though I checked with window.location.href and document.URL and get the exact same result on both Windows and iOS); the application does use 302-Redirects, but those should not affect the URL used for generating the hash on iOS (or should they?)

b. that IOS somehow ignores / modifies / changes settings from the Windows-generated config-file and therefore generates a different hash

Version Information
Please complete the following information:

• OS: iOS 26.1
• SEB Version: iOS 3.6.1 / Windows 3.10.1

[danschlet]

Is the same Config Key hash displayed in the Settings editor in SEB for iOS as in the SEB Windows Configuration Tool? I can't open your example config file, SEB for iOS doesn't accept the admin password (which is unnecessarily long, SEB is just comparing sha256 hashes of the passwords, so such a long password doesn't increase security).

[beursken]

I have attached a different SEB-Config (this time using the admin password "test" and "quit" as an unchanged quit-password):

Klausur 07-01-2026-03-09.zip

The config-keys are identical on both iOS and Windows.

However, I get different hash-values even when passing along the URL as reported by Javascript along with the hash-value itself, i.e.

$.ajax({
url: mainPath() + '/klausur/ValidateSE',
type: 'Post',
data: {
'SEBConfigKey': SafeExamBrowser.security.configKey,
'URL': document.URL
},
success: function (data) {
alert(data);
}
});

would result in

USERAGENT mozilla/5.0 (iphone; cpu iphone os 18_7 like mac os x) applewebkit/605.1.15 (khtml, like gecko) mobile/15e148 version/18.3 safari/605.1.15 seb/3.6 seb/3.5.4 seb/3.6

URL: https://pruefung.jura.uni-passau.de/klausur/1804/onscreen

Calculated ConfigKey: 9c9d82b52260ec3e26fc6853ada951a82dd96fd1351f22bdc6c2348150a20f29

Reported ConfigKey: a2c83fadabae839aaedaa88cb64501dc759b380842e17e7d52e4ac6ff6574ed9

while on Windows I get

URL: https://pruefung.jura.uni-passau.de/klausur/1804/onscreen

Calculated ConfigKey: 9c9d82b52260ec3e26fc6853ada951a82dd96fd1351f22bdc6c2348150a20f29

Reported ConfigKey: 9c9d82b52260ec3e26fc6853ada951a82dd96fd1351f22bdc6c2348150a20f29

The URL (as reported by the client itself using document.URL) is identical, yet I receive two different Hashes. Since the config-files report identical ConfigKeys the URL used by the IOS (and possibly MacOS - which I am currently unable to test) clients must be different. I am unsure how to further test this - as I do not see the URL employed for calculating the Hash (and assumed it would be the same across clients).

Note: When opening the file in the iOS-client (in Administrator-mode) I was not asked for that password (the file opened directly), whereas on Windows the password was required to view/edit settings. To simplify things I did not use a password for the exam itself for this test, so I assume that the settings file itself was not encrypted. Is this intended behavior?

[danschlet]

SEB for iOS and SEB for macOS if the modern WebView is used don't resolve AJAX URLs, you have to use the initial URL for a regular request to check the Config Key. Reason for this is that Apple doesn't give any access to XMLHttp requests (no event handler etc.).

As those SEB versions displays the Config Key correctly and the server-side implementation works correctly in numerous LMS and assessment systems, you have to look at your implementation.

If you open a config (or the client config) and then open another one with the same admin password, you don't have to re-enter that in SEB for macOS and iOS.

[beursken]

I am not using the XMLHttp-Request URL (which would be set in code anyway). I am using ajax exclusively to transfer the document URL to the server asynchronously. Normally I would only transfer the config key hash and check server side whether this matches. However to ensure that I use the actual path used on the IOS-device I transferred the local URL als reported by the local DOM on the device. I assume this is the URL used to calculate the hash-value (at least that seems to be the case on Windows).

In my understanding document.URL should be the URL of the page itself which in turn is what is used to calculate the hash (I am using the URL the browser DOM internally reports just to make sure there is no mixup, e.g. using capitalization, empty query-parameters or whatever). Still I get different results using different clients - which seems to imply that they use different paths. Since I cannot create a hash for a user-defined (relative or absolute) path I am wondering what other URL but the one reported by document.URL (or window.location.href, which is identical) could be used in calculating the hash-value...

Is the URL only determined for the initial page (i.e. the one first shown) or does it change on navigation? Does it work with server-side redirects (esp. http-code 302) or only when the path is directly accessed?

[danschlet]

I assume the problem could be related to the server-side redirects, but I don't have time to investigate that.

[danschlet]

PS: Also see this discussion: #564 (reply in thread)

Maybe such a new function would help SafeExamBrowser.security.configKeyForRelativeUrl(relative_url).

I want to propel this feature request, but because of our limited resources, it will take some time to implement and release it.