Offensive Security
What we do
Four ways into the same application, scoped as one engagement rather than bought one at a time. All of it is a person going through your software by hand, not a tool scanning it.
01 / Offensive Security
Web Application Penetration Testing
We go through your application by hand, as each kind of user, and try to get at things that user should not reach. You get back what worked, and what to change.
What we test
-
Manual testing
The application is worked through by hand, role by role and feature by feature, rather than handed to a scanner and reported on.
-
Authentication and authorisation testing
Login, session establishment, multi-factor flows where they exist, and whether each role can reach only what it is supposed to reach.
-
Input validation and injection testing
SQL, command, template and similar injection classes, and how the application behaves on input it did not expect.
-
Session and security control testing
Session lifetime and invalidation, cookie attributes, CSRF defences, and the security headers the application relies on.
-
Business logic testing
Whether the application's own rules on limits, sequences, prices and ownership hold when a user does not follow the intended path.
-
Client-side security testing
Cross-site scripting, DOM-based issues, client-side access control, and data the front end exposes that the back end assumes is hidden.
02 / Offensive Security
API Penetration Testing
Your API is the part behind the screens that holds the data. We talk to it directly, the way an attacker would, instead of going through your app and following its rules.
What we test
-
Authentication
How tokens, keys and sessions are issued, validated, refreshed and revoked, and what happens when one is absent, expired or altered.
-
Authorisation
Whether an endpoint enforces the caller's role on every method it exposes, not only on the ones the official client uses.
-
Object-level access control
Whether an authenticated caller can read or change another user's or another tenant's objects by changing an identifier.
-
Input handling
Injection, type confusion, mass assignment, and parameters an endpoint accepts but was never meant to.
-
Rate limiting
Whether limits exist on the endpoints that need them, and whether they can be bypassed or exhausted.
-
API business logic
Sequences and state transitions the client enforces politely and the API does not enforce at all.
03 / Offensive Security
Authentication & Authorisation Testing
Can one customer see another customer's data? Can a normal user do an admin's job? This is the shorter engagement for when that is the question that keeps you up.
What we test
-
Broken access control
Endpoints, objects and functions reachable by users who should not reach them, both across accounts and up through roles.
-
Privilege escalation
Paths from a low-privilege account to a higher-privilege one, including through features built for administrators.
-
Session management
Issue, renewal, expiry and concurrent sessions, and what a logout actually invalidates.
-
Account recovery
Password reset, email change and recovery flows, which are routinely weaker than the login they can bypass.
-
Role separation
Whether roles are enforced on the server or only reflected in what the interface chooses to render.
04 / Offensive Security
Business Logic Testing
Paying less than the price. Using a discount twice. Approving your own request. Nothing is broken here, so no tool will tell you about it. We start from how your business is supposed to work and try to bend it.
What we test
-
Workflow abuse
Steps skipped, repeated or taken out of order, and states reached that the design does not account for.
-
Trust boundary violations
Values the server accepts from the client when it should be deciding them itself: prices, totals, roles, identifiers, entitlements.
-
Race conditions
Where they are relevant: concurrent requests against balances, stock, redemptions and actions meant to happen once.
-
Payment and order manipulation
Quantities, currencies, refunds, vouchers and totals, tested for outcomes the business would not accept.
-
Abuse of intended functionality
Features working exactly as built, used at a scale or in a direction nobody designed for.
Beyond the test
The defensive half is Skull Solutions
A test tells you what is reachable today. How the application should have been designed, and the engineering that closes what we find, belongs to our parent company rather than to us.
-
Application security consulting
Security architecture review, threat modelling, secure code review and attack surface review: how the application was designed, and what it was meant to defend against.
-
Secure software engineering
Closing findings in your codebase, and building the parts where getting the security wrong is the whole risk. Not general development, and never a product build with a security label on it.
Ask us about either and we will point you at Skull Solutions rather than stretch a testing engagement to cover it. Remediation stays your engineers' work by default: our report names the check that is missing and where it belongs, which is what most teams need to close a finding themselves.
Engagements
How an engagement runs
Scope, test, report, retest. Nothing is tested before the scope is agreed in writing, and every finding is verified by hand before it reaches you. See the four stages.
Authorisation and remediation
If the system belongs to someone else, such as a platform your application runs on or a supplier who hosts it, we need their sign-off as well as yours.
Remediation is your engineers' work, and the report is written for them: it names the check that is missing and where it belongs. A retest of those findings is included for fifteen days. Past thirty days, or after a substantial change to the application, a new assessment is usually a more honest answer than a retest of a report written against something else.
Want the specifics?
Have something tested
Describe the application and what it handles. We will tell you what is worth testing.