How XSS can defeat your digital signatures

Recently we exploited nice XSS vector in one of RBS (Remote Banking Service) system. This example shows very well how dangerous can be client-attack.

Client after the authorization could sign electronic documents.
For signature from browser developers used CAPICOM technology.

If you are already understood us, you can not finish this note ;)

Signature from JavaScript - this is easy and usefull from client-side attacks.
JS code for sign document looks like:

function SignCreate(certSubjectName, dataToSign) {
    var oStore = CreateObject("CAPICOM.Store");
    oStore.Open(CAPICOM_CURRENT_USER_STORE, CAPICOM_MY_STORE,
    CAPICOM_STORE_OPEN_MAXIMUM_ALLOWED);

    var oCertificates = oStore.Certificates.Find(
    CAPICOM_CERTIFICATE_FIND_SUBJECT_NAME, certSubjectName);
    if (oCertificates.Count == 0) {
        alert("Certificate not found: " + certSubjectName);
        return;
    }

    ...

You can easily call this function from stored/reflected XSS to sign arbitrary data.
To solve the PIN entry problem, we have used the caching mechanism for the key. Most often, after entering the PIN code of the key, PIN is remembered for a while.

So we were able to sign arbitrary (injected) document immediately after the user signs his own document (and entered PIN of course).

Then, using the Javascript we were able to hide the injected signed document from users's orders table (document was order request) for current user.

So only a single stored XSS vulnerability defeated all security measures of the RBS system. Note, that typically protections such as httpOnly cookies and SSL have been included, but it does not help.