Услуга · Тестирование и QA

Security testing

We find the weak points before those looking for them from outside with bad intentions. We work strictly to agreed rules, in an agreed window and without destructive actions. This is a controlled test, not a break-in.

Permission
in writing and in advance
Carefully
without destructive actions
Priorities
what to fix first
Re-testing
after your fixes

What the work includes

We look at what gets attacked most: the login mechanism, permissions, input handling and third-party components.

Discuss the scope

Authentication

Bypassing the login, weak passwords, insecure password recovery, session lifetime.

Permission separation

Whether a user can get someone else's data by substituting a different identifier. The most common finding.

Input handling

Injection into database queries, script execution in the browser, uploading dangerous files.

Components

Third-party libraries with publicly known vulnerabilities. A modern project has dozens of them.

The environment

Exposed admin URLs, debug mode left on, unnecessary headers, accessible archives and backups.

Отчёт

Findings with a severity rating, the steps to reproduce and recommendations for fixing them.

How it goes

A typical web application is tested in one or two weeks including preparing the report.

01

The agreement

Written permission, the scope, the testing window, contacts for urgent communication.

02

Reconnaissance

We gather information about the application: entry points, the technologies used, exposed interfaces.

03

Проверка

By hand and with tools, in a gentle mode, without actions that could disrupt operations.

04

Отчёт

The findings in priority order, and after your fixes a re-test of what was closed.

A list of vulnerabilities is a document you cannot email to just anyone. It describes in detail how to reproduce every finding, and until they are fixed it is more dangerous than the vulnerabilities themselves. We hand it over securely and to a limited circle.

Questions and answers

It is lawful with the written permission of the system's owner. We work strictly under contract, with defined boundaries and timing. Testing someone else's systems without permission is not allowed and we do not do it.

We work carefully and without destructive tests. Even so, any such work carries risk, so a test copy is preferable, and on a live system an agreed window with a fresh backup ready.

A scanner checks against a database of known signatures and is good at finding outdated components. Logic flaws - access to other people's data, bypassing rules, wrongly granted permissions - are seen only by a person. Proper work combines both approaches.

We will look for holes in the application

Describe the application and say whether there is a test copy. We will agree the boundaries and run the test.