Optional security checks explained: account creation, executable files, command execution and data import
Published 5 min read
Also available in: 日本語 · 中文 · Español · Français · Deutsch · Português
Key points
- The standard diagnosis consists mainly of read-only checks, limited to what the consent text discloses. The four optional items can leave traces on the target while verifying, so they run only when you authorize each one.
- Traces remain only if the target actually has the weakness. Otherwise the requests are rejected, and only the request entries in your access logs remain.
- Authorized items are added from the next month's diagnosis and can be removed at any time. The report records which items ran and how to clean up anything that may remain.
Contents
- Standard checks, optional checks and checks we never run
- What all optional items have in common
- Verifying by creating an account
- What it tests
- What is sent
- What may remain if the weakness exists
- How to clean up
- Before you enable it
- Verifying by placing an executable file
- What it tests
- What is sent
- What may remain if the weakness exists
- How to clean up
- Before you enable it
- Verifying by executing a command
- What it tests
- What is sent
- What may remain if the weakness exists
- How to clean up
- Before you enable it
- Verifying by importing data
- What it tests
- What is sent
- What may remain if the weakness exists
- How to clean up
- Before you enable it
- Consent and responsibility
SPHIOR's diagnosis has checks that run by default and checks that run only when you authorize them item by item. The latter can find more serious weaknesses, but in exchange they may leave traces on the target while verifying.
This page exists so that you can understand concretely what will happen before you tick each item on the consent screen.
Standard checks, optional checks and checks we never run
| What it covers | Effect on the target | |
|---|---|---|
| Standard | Reading public pages and settings, submissions (POST) that test how input is handled, upload checks that place a harmless randomly-named file, and a single login attempt to see whether a default password is still in use | A failed login or a harmless test file may remain (disclosed in the consent text) |
| Optional | Checks that verify by creating an account, placing an executable file, executing a command or importing data | If the corresponding weakness exists, the traces described for each item below may remain |
| Never run | Changing settings, deleting data, resetting passwords or re-running initial setup, sending many requests simultaneously, sending more than 200 requests in a single check, and HTTP methods that write or delete data (PUT / PATCH / DELETE) | Not performed under any consent |
The four optional items also never send HTTP methods that write or delete data. Checks that involve deleting, resetting or overwriting are excluded in advance.
What all optional items have in common
- Traces remain only when the weakness exists. On a target without the weakness, the requests are rejected and nothing is created. In every case, however, the requests are recorded in the target's access logs.
- They start with the diagnosis in the month after you authorize them. Untick an item and it no longer runs from the following month.
- They are recorded in the report. The "Scope and methodology" chapter lists the items you consented to and how many checks were added; the "Finding details" chapter states, for each finding from an optional check, what may remain and how to clean it up.
- The values we send are harmless test values. We never use real users' information or your data.
Verifying by creating an account
What it tests
A weakness that lets anyone create user or administrator accounts without authentication. It is caused by misconfigured public registration or administrative functions. If exploited, a third party can get in as a legitimate user.
What is sent
Requests that create a test account. The name, email address and password are either fixed test values defined for each check or random values.
What may remain if the weakness exists
- The test account (it may have user or administrator privileges)
- For some checks, a test registration other than an account
- Notifications triggered by account creation (notification emails to administrators, welcome emails and so on, depending on your system's settings)
How to clean up
Starting from the location in the finding, find the test account in your admin console or similar and delete it. Left in place with privileges, it can itself become an entry point.
Before you enable it
If you report user counts externally, or account creation is tied to other processes such as billing or inventory, decide in advance how test accounts should be handled.
Verifying by placing an executable file
What it tests
A weakness that lets a file executed by the server (such as a script) be placed through an upload function or similar. It opens the door to arbitrary code execution and is one of the most serious kinds of weakness.
What is sent
A test file. Its content only displays a fixed string, a calculation result or the value it receives, or is just a random string; it has no ability to execute commands. We then access the placed file and confirm from the response whether it was executed.
What may remain if the weakness exists
- An executable test file on the target server
How to clean up
Starting from the location in the finding, find the test file and make sure to delete it. Its content only displays output, but leaving an executable file in a public location is undesirable in itself. Also review the settings so that uploaded files cannot be executed (separate storage location, no execute permission, extension restrictions).
Before you enable it
If you use file tamper detection or monitoring of file changes on the server, the test file may trigger an alert. Letting the responsible team know in advance avoids confusion.
Verifying by executing a command
What it tests
A weakness that lets external input cause OS commands to run on the server. It is a serious kind of weakness that can lead to a server takeover.
What is sent
A command that confirms the result: displaying the user the process runs as, reading a system configuration file, displaying a fixed string, or a calculation. Checks that involve writing or deleting are excluded in advance. The content of the response is not included in the report; only its fingerprint (hash) is kept.
What may remain if the weakness exists
- A record that a command was executed on the server (OS or application logs)
- The commands do not create files, but their execution may be detected by monitoring tools
How to clean up
No files remain. Fix how input is handled at the location in the finding, and check whether the execution traces in your logs come from this check by comparing them with the dates in the report.
Before you enable it
If you use intrusion detection (EDR, IDS and similar), the test commands may raise alerts. Sharing the diagnosis schedule with the responsible team helps avoid treating them as a real attack.
Verifying by importing data
What it tests
A weakness that lets data be imported without authentication. A third party could register fake data or use the import function as a stepping stone to other weaknesses.
What is sent
A small amount of harmless test data.
What may remain if the weakness exists
- The imported test data (it may appear in lists or admin screens)
How to clean up
Starting from the location in the finding, find the imported test data and delete it.
Before you enable it
If imported data automatically flows into other processes (aggregation, delivery, integrations with external services), the test data may reach those as well.
Consent and responsibility
You authorize the optional items at your own discretion, after understanding the traces and effects described above. The consent text states that you accept those effects, and that all other matters are governed by the Terms of Service (Section 10, Limitation of Liability).
If you are unsure, you can start with the standard diagnosis only and add items after reviewing the report. Optional items can be added or withdrawn at any time.