Malicious Attachment

Malicious_Attachments

1. Introduction

Attaching Malicious files to a request can have several purposes:

  • Corrupted or very large files intended to make the server to crash.
  • Files containing code that is harmful for the server to execute/parse, i.e. a virus targeted at the server.
  • Files containing code that is harmful for clients to execute/parse, i.e. a virus targeted at users, passed via the server.

The Malicious Attachment Security Scan allows generation of corrupt files as well as attachment of user-selected files.

1.1. Typical real-world attack

The typical attack differs a lot depending on the purpose of the attack (see Introduction above). With this being said, one example could to upload a corrupted JPEG image to a web gallery, with the intentions to crash the web server. When the target is instead end-users, a malicious attachment can be masked to look like a harmless file, e.g. hilariousPhoto.jpg.com (files with the COM-file extension is executable in Microsoft Windows).

1.2. What it does

This scan adds and/or replaces already existing attachments to the request. It tries to send invalid or large attachments to server so that error can be provoked and/or security be compromised.

2. Usage

In table 1_snag_evi is a list of existing attachments added to request, those you can see in functional test, too. In table 6_snag_evi user can add new attachments. These attachments do not exist on disk and they will be genrated when test is beeing run and they will be sent along with existing attachments. In table 7_snag_evi user can add new attachments, too. These attachments exist on user disk and they will be sent with alredy existing attachments (  1_snag_evi ) and generated ones ( 6_snag_evi ). If check box 8_snag_evi is selected than existing attachments ( 1_snag_evi ) will be replaced with attachments from table 7_snag_evi.

Then add assertions using the controls at the bottom of the window 5_snag_evi that checks if the Malicious Attachment caused any trouble on the server. Some assertions that would typically make sense are:

  • Response SLA, to make sure that the targeted service is still responding after a reasonable amount of time.
  • Sensitive Information Exposure, to make sure that no server internals are exposed (e.g. via stacktraces if the server crashes).
  • Contains, e.g. to make sure that the web page that the user is forwarded to does not contain signs of the malicious attachment, exposed to other users.

These assertions will be added/suggested automatically if the Security Test is generated by the Security Test Wizard in ReadyAPI.

2.1. Configuration

The Strategy tab 3_snag_evi lets you configure whether the scan should be run on failed TestSteps, how long it should wait between each request.

From the Advanced tab 4_snag_evi you can set the timeout in milliseconds for the request.

3. Prevention & Further reading

Never trust user-submitted attachments. Make sure to handle extreme cases like huge files and corrupted files.