Mst DevSec

👨‍💻💫

[Mst DevSec @MstDevSec]

Don't forget to check out subdomains while exploring 🫡

#bug #bugbounty #recon #vulnerability

[Mst DevSec @MstDevSec]

A reset link has four trust boundaries: cryptographic randomness → short lifetime → one-time use → binding to the right account and action. A missing property creates a distinct path for guessing, replay, or reuse in another flow.

#AppSec #Authentication #cybersecurity

[Mst DevSec @MstDevSec]

A password-reset token is not safe merely because it looks long. A review of NivoCart 2.4.0 found weak generation and no expiry, creating an account-takeover risk; the recovery flow could also be disabled separately.

[Mst DevSec @MstDevSec]

In a multi-step flow, “Can this proceed before the previous step is complete?” is a starting question. The answer only makes sense against the app's expected rule. An address list becomes test questions with a reason behind them. #BugBounty #Recon

[Mst DevSec @MstDevSec]

Recon means getting to know the target, including what its addresses are for. Following a normal flow with a test account in an authorized app brings the screen, account role, data and network request into the same notes.

[Mst DevSec @MstDevSec]

The interesting part: the client had an OTP verification flow, but the server-side endpoint did not enforce it. A reminder that client-side checks are not security controls. The issue was responsibly disclosed. 🔐 #BugBounty #AppSec

[Mst DevSec @MstDevSec]

I found a critical account security flaw in a web app: its phone-number change API accepted an attacker-controlled number and marked it as verified without requiring OTP verification. What looked like a validation bug had deeper impact. 👇

[Mst DevSec @MstDevSec]

The phone number was not just profile data. It was used in SMS-based authentication and other security-sensitive flows. An authenticated attacker could bind their own number to the account without the current password or an OTP for the new number.

[Mst DevSec @MstDevSec]

Relevant request/response excerpts support the evidence; passwords and session secrets stay out. Someone else's sensitive data means stopping and notifying the program privately without copying it. More data doesn't mean clearer evidence. #BugBounty #AppSec

[Mst DevSec @MstDevSec]

Useful questions for bug bounty evidence: What's the test account's role? Is it the researcher's own test data? What was expected, and what happened? Showing what changed and what stayed fixed helps explain why the difference matters.

[Mst DevSec @MstDevSec]

System and app logs are separate evidence. A report can hide the sensitive value while showing when and where it was written and who can read it. The fix is to keep that data out of logs; fewer messages alone do not establish safety.
#MobileSecurity #AppSec

[Mst DevSec @MstDevSec]

For mobile logs (event records), the build matters: development and distributed versions may produce different output. In authorized tests with sample data, login and error flows show whether passwords or values representing a session reach logs.

[Mst DevSec @MstDevSec]

Android App Links verifies the website–app association, not user permissions. The evidence is whether the server returns private data to a test account without access, not merely whether a screen opens. #MobileSecurity #AppSec

[Mst DevSec @MstDevSec]

An Android deep link opens a screen in an app. Is the content private? In an authorized test, useful cases are signed out, then a test account without access to the record. Public content not requiring login is not a finding by itself.

[Mst DevSec @MstDevSec]

5. The account role needed for the action
6. Request inputs and selected record
Address → action → permission question.
Actions with user-selected records merit a closer look. An archived address proves neither live use nor test permission. #BugBounty #Recon

[Mst DevSec @MstDevSec]

Recon checklist: getting to know the target
Within authorized scope:
1. Domains and web services
2. Addresses seen in normal use
3. Address candidates in browser code and archives
4. Each address's screen and action

[Mst DevSec @MstDevSec]

Two useful points for this search display:

-textContent inserts input as plain text, not code.
-Inserting it as HTML (page markup) can make the browser interpret it as code.

The fix is in how the search term is displayed, not in the term itself.

#XSS #BugBounty

[Mst DevSec @MstDevSec]

Seeing “test123” on a results page after typing it into search is normal. That alone is not XSS. XSS means user-supplied content can run unwanted code in the browser as part of the site.

[Mst DevSec @MstDevSec]

Example read expectations (not tested):
Account | A's document | B's document
A | allow | deny
B | deny | allow
Actual results are separate from this policy. Every request failing does not prove correct access control. #AppSec #APISecurity

[Mst DevSec @MstDevSec]

Example for an authorized test: A and B have the same role and may read only their own private documents; sharing is off. A working read of each account's own document provides a baseline for interpreting a cross-account denial.