Cross-Site Scripting

Cross-site scripting vulnerabilities enable an attacker to trick the user’s browser into running code (such as JavaScript, Java, Flash, ActiveX, or VBScript) that is treated as trustworthy, thereby allowing the attacker to obtain a copy of the session ID or inject malicious code into web pages viewed by other users.

Defenses

To make cross-site scripting more difficult, you can:

  • Verify the web user’s IP address. You can retrieve the Web user’s IP address using $webinfo("WEBSERVERCONTEXT") to obtaing the REMOTE_ADDR property and store it as part of the session state. With each request, you can validate the IP address in the preRequest trigger or, on each component, in the preActivate trigger.

    However, this does not prevent attacks by someone who shares the same IP address. It can also be frustrating for mobile users whose IP address is liable to change during a browser session. This method is also vulnerable to identity spoofing. For more information, see Identity Spoofing.

  • Change the value of the session ID with each request in the postRequest trigger, and validate that in the preRequest trigger against the persisted server side state. This reduces the window of opportunity for an attack, and makes it easy to identify whether an attack has taken place.

    However, this has a serious side effect for browser usability because using the back button will also trigger an invalid session ID.

    You can regenerate a session ID in ProcScript using the following code, which uses a generated UUID encoded with a random key: 

    variables
  string vSessionId, vRandomKey
endvariables

; Generate the session ID 
vRandomKey = "GsbnFhyaPF11jIWyFaCu9zogqJALG50NDGXL0clX1"
vSessionId = $encode("HEX",$encode("HMAC_MD5", $uuid, vRandomKey))

    The stored state needs to be updated to contain this new session ID. For more information, see State Management Mechanisms.

Related Topics