GoScript

GoScript is a custom scripting language that has been developed in-house by AppCheck penetration testers to model “user journeys” – multi-step flows through complex web applications – through modelling in an easy to grasp code a desired series of discrete steps or interactions used to navigate or manipulate a web application. These can include interactions including text entry, page navigation, mouse clicks and page element manipulation within the browser DOM (Domain Object Model). The syntax for GoScript has been designed to be simple, memorable, and easy to learn and use and does not require you to be a developer in order to make use of it.

Once written, GoScript can be attached to selected scan configurations within AppCheck, allowing customers to combine the power of automated scanning with a human-like understanding of how to step through complex user journeys and processes such as user registration flows or basket checkouts on e-commerce sites. This modelling of complex and multi-stage user journeys within the application enables the scanner to both access “deep” sections of a web application that could not otherwise be reached, as well as to manipulate complex forms or areas of the application which require specific contextual input and might otherwise be impossible for an automated scan to test.

GoScript is often used to provide guidance to the scanner on how to login via complex authentication systems such as Single Sign On (SSO) processes, thereby granting access to pages and areas of a web application that are screened behind authentication barriers and that otherwise may not be accessible for vulnerability testing.

GoScript can also be used to navigate complex flows involving multiple stages, forms, or screens, navigating them as a user would. One example of this is the shopping cart journey in ecommerce application which can be modelled, to include all stages and options available in the payment flow to ensure good coverage by the security testing plugins.

For more information please see:

• AppCheck – Single Page Applications
• AppCheck – A Guide to GoScript

Card Skimmers

Criminals often look to obtain payment card details belonging to other people since these can be used for financial gain, either by using the card details directly for purchases or by selling the card details to another party, often in bulk.

A relatively common method of accomplishing this in the physical world is to discretely attach malicious devices known as card skimmers to hardware such as ATM machines or legitimately installed card readers in retail establishments. Victims unaware of the malicious devices will insert their card into the hardware reader (for example ATMs and PIN Entry Devices), and the malicious device can then intercept and read the payment card information from the chip or magnetic strip of the card as it passes through.

However, physical card skimmers have several disadvantages for an attacker, not least that they require the attacker to physically gain access to the target card reading device – once to install the malicious card skimmer, and typically a second time (if it is not for example wireless-enabled) to recover it and retrieve the stolen card information that it has captured. This increases the chances that they may be observed, challenged, and caught, and the attack cannot easily be scaled since every card reader must be compromised physically with a directly attached card skimmer device. For this reason, many criminals have instead switched to exploiting online payment portals via equivalent virtual as opposed to physical card skimming methods, to steal card information.

Web applications such as online stores will usually require users to enter their card details into the application to facilitate payment during order placement. Attackers can target these retail applications and exploit vulnerabilities in them in order to embed virtual card skimmers to steal card details that are submitted to them. One of the most common methods of doing this is to use what is known as a JavaScript card skimmer. This type of card skimmer can be maliciously injected into the webpage served by the application, by compromising the hosting payment server. When compromised, the malicious code is sent to – and executed by – a visiting customer’s web browser, capturing and sending their entered card details to an attacker directly from the victim’s browser.

The most direct method that can be used by attackers is to directly compromise the web application and modify it to serve the malicious JavaScript provided by the attacker. However, the scale of the attack can be magnified many times over if it is found to be possible to compromise not a single target web application, but a shared third-party source used to serve legitimate JavaScript that many applications utilise. This second type of attack is possible because it is very common for web applications to include third-party standard JavaScript libraries directly where these are made available to provide standard functionality that can be called by a developer from their own code to save the developer having to write their own code for common functionality.

Since it is not trivial to develop successful exploits, once code that delivers JavaScript card skimming functionality has been developed by an attacker and proven successful, it is often shared and reused between different attackers and groups: AppCheck’s scan engine therefore contains several plugins that have been developed to recognise code containing known card skimming functionality and identify if it is being unknowingly served or loaded by a scanned web application.

In addition to “known bad” JavaScript that can be matched against recorded code patterns from past exploits, any JavaScript loaded from third party sources at all is an inherent security risk more generally and is something AppCheck will warn of if found during scanning. The risks here is that since JavaScript hosted on and loaded from a third-party system can be changed at any time by anyone with access to the third-party site and without the client (calling) web application that references it being aware of the change, malicious code could be substituted in for the legitimate code at any time. AppCheck will therefore report warnings wherever any JavaScript is loaded in this manner from a third-party host or provider, as well as reporting resources which the application is attempting to load from domains that can be hijacked by an attacker.

Additional Information

As always, if you require any more information on this topic or want to see what unexpected vulnerabilities AppCheck can pick up in your website and applications then please get in contact with us: info@localhost