[{"content":"How to Think Like a Hacker: 8 Mindset Methods for Security Researchers Tools matter. Payloads matter. Labs matter.\nBut a professional hacker is not defined by the tools they run. A professional hacker is defined by how they observe, question, decompose, test, and connect weak signals into real impact.\nThis article summarizes practical thinking methods that help ethical hackers, pentesters, and security researchers move from “running checks” to thinking like an attacker with engineering discipline.\nImage: Type: (Context), Mô tả: \u0026ldquo;A simple visual showing a hacker mindset loop: Observe → Question → Test → Chain → Report.\u0026rdquo; caption: \u0026ldquo;Hacker mindset is a repeatable thinking loop, not random guessing.\u0026rdquo;\n1. Adversarial Thinking Adversarial thinking means looking at a system from the perspective of someone who wants to abuse it.\nDo not only ask:\nHow is this feature supposed to work?\nAsk:\nHow can this feature be bypassed, misused, or chained with something else?\nFor example, when testing a login flow, a normal user sees username, password, and submit. A hacker sees rate limits, password reset logic, session handling, MFA bypass possibilities, error messages, cookies, and account enumeration behavior.\nPractice For every feature you test, write down at least three attacker questions:\nWhat can I modify? What does the server trust? What happens if I skip this step? What happens if I repeat this request? What happens if I perform this action as another user? 2. Reverse Thinking Reverse thinking means asking how something breaks instead of only asking how it works.\nA developer may think:\nThe user must complete step 1 before step 2.\nA hacker asks:\nWhat if I send the step 2 request directly?\nThis mindset is useful for authentication, authorization, checkout flows, approval workflows, file upload flows, and password reset mechanisms.\nPractice Take one normal workflow and reverse it:\nStart from the final action. Replay the request without previous steps. Change object IDs, roles, quantities, tokens, and headers. Remove optional-looking parameters. Compare how the server responds. Image: Type: (Test case), Mô tả: \u0026ldquo;A workflow diagram showing normal order: Step 1 → Step 2 → Step 3, then a bypass attempt calling Step 3 directly.\u0026rdquo; caption: \u0026ldquo;Reverse thinking tests whether server-side state is actually enforced.\u0026rdquo;\n3. Logic Abuse Thinking Many serious vulnerabilities are not caused by broken syntax. They are caused by broken business rules.\nLogic abuse means using valid functionality in an unintended way.\nExamples:\nChanging user_id in an API request to access another user’s data. Applying a coupon multiple times. Reusing a password reset token. Changing product quantity to a negative value. Sending two requests at the same time to exploit a race condition. Practice When testing business logic, focus on:\nOwnership Role Sequence Quantity Price Time Token lifetime Approval state Repetition Race condition A strong hacker does not only ask, “Is this input vulnerable to SQL injection?” They also ask, “Can the business process itself be abused?”\n4. Attention to Detail Professional hackers notice things others ignore.\nSmall details often reveal large attack paths:\nUnusual HTTP headers Verbose error messages Hidden input fields JavaScript endpoints Debug parameters Redirect behavior Different responses for valid and invalid users Cache headers Inconsistent authorization checks Practice When using Burp Suite, do not only look at whether the request succeeds or fails. Compare:\nStatus code Response length Error message Redirect chain Cookies Headers Timing Object IDs Role-dependent differences Create an “anomaly log” while testing. Every strange behavior should be recorded, even if it does not look exploitable immediately.\nImage: Type: (PoC), Mô tả: \u0026ldquo;A Burp Suite Repeater screenshot with highlighted status code, response length, Set-Cookie, and hidden API endpoint in JavaScript.\u0026rdquo; caption: \u0026ldquo;Small HTTP differences can expose authorization, session, and logic flaws.\u0026rdquo;\n5. Strategic Trial-and-Error Hacking requires experimentation, but professional experimentation is structured.\nRandom payload spraying is weak testing. Strategic trial-and-error follows a sequence:\nEstablish a baseline. Modify one variable. Observe the difference. Increase complexity. Try encoding or parser confusion. Document what changed. For example, when testing input validation, do not start with the most complex payload. Start simple, then mutate:\ntest \u0026#39; \u0026#34; \u0026lt;test\u0026gt; ../../etc/passwd {{7*7}} http://127.0.0.1 The goal is not to “throw payloads.” The goal is to learn how the application parses, filters, stores, and reflects data.\n6. System Decomposition A web application is not one object. It is a system of components.\nA hacker decomposes the target into smaller parts:\nFrontend Backend API Authentication Authorization Session management Database File storage Background workers Cache CDN Third-party integrations Admin panels Logging and monitoring Once the system is decomposed, attack surfaces become clearer.\nFor example, a file upload feature may involve:\nBrowser upload form API endpoint File type validation Object storage CDN delivery Image parser Admin review panel Each component has different risks.\nPractice Before testing a target deeply, draw a simple system map:\nUser → Frontend → API Gateway → Auth Service → Backend → Database ↓ File Storage → CDN Then ask: where are the trust boundaries?\n7. Zero-Trust Mindset A hacker should not trust the UI, the client, the token, the role, or the request sequence.\nClient-side controls are not security boundaries.\nIf a button is hidden in the UI, test the backend request directly. If a role is shown as read-only, try the write request anyway. If a JWT is present, inspect its claims and validation behavior. If a parameter is not visible, check JavaScript, traffic, and API schemas.\nPractice For every request, ask:\nIs authorization checked server-side? Can this object ID be changed? Can this role be modified? Can this token be reused? Can this request be replayed? Can this action be performed out of order? Zero trust is one of the most important mindsets for finding IDOR, BOLA, privilege escalation, and workflow bypass vulnerabilities.\n8. Chaining Mindset A single low-severity issue may not matter. But two or three weak signals can create serious impact.\nExamples:\nInformation disclosure + IDOR = sensitive data exposure Stored XSS + admin panel = account takeover SSRF + cloud metadata = credential exposure File upload + parser weakness = code execution Weak reset token + user enumeration = account compromise Professional hackers constantly ask:\nWhat does this finding enable next?\nPractice After every finding, write:\nWhat can I access now? What new information did I learn? What trust boundary did I cross? Can this be combined with another weakness? What is the real business impact? Image: Type: (Context), Mô tả: \u0026ldquo;A chain diagram showing Information Leak → IDOR → Sensitive Document Access → Business Impact.\u0026rdquo; caption: \u0026ldquo;Impact often comes from chaining small weaknesses.\u0026rdquo;\nA Practical Hacker Mindset Checklist Use this checklist during testing:\nQuestion Purpose What does the server trust? Find trust boundary issues What can I modify? Identify controllable inputs What happens if I skip a step? Find workflow bypass What happens if I change role or object ID? Find authorization flaws What happens if I repeat this action? Find replay or race issues What hidden endpoints exist in JavaScript? Expand attack surface What small anomaly did I observe? Track weak signals What can this bug be chained with? Increase real impact Vietnamese Summary Tư duy hacker chuyên nghiệp không phải là đoán mò hoặc chạy tool hàng loạt. Đó là khả năng nhìn hệ thống theo góc nhìn đối nghịch, đặt câu hỏi về trust boundary, kiểm tra logic nghiệp vụ, quan sát chi tiết nhỏ, thử nghiệm có hệ thống, phân rã hệ thống và biết cách chain các điểm yếu nhỏ thành impact thật.\nNếu bạn đang học web pentest hoặc bug bounty, hãy luyện 8 tư duy chính:\nAdversarial thinking Reverse thinking Logic abuse thinking Attention to detail Strategic trial-and-error System decomposition Zero-trust mindset Chaining mindset Một hacker giỏi không chỉ hỏi “payload nào dùng được?”. Họ hỏi: hệ thống này tin vào điều gì, và niềm tin đó có thể bị phá vỡ như thế nào?\nFinal Thought Thinking like a hacker is a discipline.\nIt is not about being chaotic. It is about being curious, skeptical, structured, and precise.\nThe better your questions, the better your findings.\n","permalink":"https://kevinsec.io/blog/how-to-think-like-hackers/","summary":"A practical mindset guide for ethical hackers, pentesters, and security researchers who want to move beyond tools and think in systems.","title":"How to Think Like a Hacker: 8 Mindset Methods for Security Researchers"},{"content":"API BOLA Explained with Realistic Examples Broken Object Level Authorization (BOLA) is one of the most important API security issues.\nIt happens when an API exposes an object identifier and fails to verify whether the current user is allowed to access that object.\nThe vulnerable pattern looks simple:\nUser A requests object ID 1001 -\u0026gt; API returns object 1001 User A changes object ID to 1002 -\u0026gt; API returns object 1002 even though it belongs to User B This is the API version of a very common access control failure. In older web security language, it is often discussed as IDOR. In modern API security, BOLA is the broader and more API-focused category.\nImage: Type: Context. Mô tả: \u0026ldquo;A diagram showing User A sending an API request for object 1001, then changing the object ID to 1002, with the API missing an authorization check.\u0026rdquo; caption: \u0026ldquo;BOLA appears when object identifiers are checked for existence, but not ownership or permission.\u0026rdquo;\nContext APIs expose object identifiers everywhere:\nUser IDs Order IDs Invoice IDs Ticket IDs Project IDs Organization IDs File IDs Message IDs Payment method IDs Workspace IDs Tenant IDs Example API request:\nGET /api/v1/invoices/1001 HTTP/1.1 Host: api.example.com Authorization: Bearer \u0026lt;token\u0026gt; The API authenticates the user, finds invoice 1001, and returns it.\nThe missing question is:\nDoes this authenticated user have permission to access invoice 1001?\nAuthentication answers “who are you?”\nObject-level authorization answers “are you allowed to access this specific object?”\nBOLA happens when the second question is skipped.\nRoot Cause BOLA usually appears because the backend checks only part of the security logic.\nCommon root causes:\nThe API verifies that the user is logged in but not that the object belongs to the user. The API trusts object IDs from the client. Authorization is enforced in the frontend but not the backend. Developers assume UUIDs are unguessable and therefore safe. The API uses direct database lookups by ID without scoping the query to the current user or tenant. Different endpoints use inconsistent authorization middleware. Internal APIs become exposed without adding object-level checks. A vulnerable backend query may conceptually behave like this:\nFind invoice where id = requested_id A safer query behaves like this:\nFind invoice where id = requested_id AND owner = current_user In multi-tenant systems, the authorization boundary may be user, organization, role, project, or workspace.\nImpact BOLA can expose or modify data across users and tenants.\nPossible impact includes:\nReading another user\u0026rsquo;s profile Downloading another user\u0026rsquo;s invoice Viewing another customer\u0026rsquo;s support ticket Editing another user\u0026rsquo;s address Canceling another user\u0026rsquo;s order Accessing another organization\u0026rsquo;s project Reading private files Changing another user\u0026rsquo;s settings Performing actions across tenant boundaries BOLA impact increases when the affected object contains personal data, financial data, business data, authentication settings, or privileged actions.\nImage: Type: Test case. Mô tả: \u0026ldquo;A lab API test using two test accounts. Account A requests its own object, then tries Account B\u0026rsquo;s object ID. Show the expected access denied result or vulnerable result in a lab.\u0026rdquo; caption: \u0026ldquo;BOLA testing requires at least two users or roles to validate object-level authorization.\u0026rdquo;\nSignature Look for API requests that include object identifiers.\nCommon patterns:\nGET /api/users/123 GET /api/orders/98765 GET /api/invoices/2026-001 GET /api/projects/abc123/files/file789 PUT /api/profile/address/555 DELETE /api/messages/9001 POST /api/workspaces/77/invite Identifiers may appear in:\nURL path Query string Request body Headers GraphQL variables JSON arrays Batch operations WebSocket messages Do not ignore UUIDs. BOLA is not about whether the ID is easy to guess. BOLA is about whether access to that object is authorized.\nRealistic Examples Example 1: Invoice Download User A downloads an invoice:\nGET /api/invoices/inv_1001 Authorization: Bearer token_user_a Then User A changes the invoice ID to another value discovered from an email, URL, receipt pattern, or browser history.\nThe API should return 403 Forbidden or 404 Not Found if User A does not own that invoice.\nIf the API returns another user\u0026rsquo;s invoice, this is BOLA.\nExample 2: Support Ticket Access A SaaS application exposes:\nGET /api/tickets/8842 If users from one organization can access tickets from another organization by changing the ticket ID, the issue becomes cross-tenant data exposure.\nThis is often high severity in B2B applications.\nExample 3: Updating Another User\u0026rsquo;s Resource BOLA is not only about reading data.\nExample:\nPUT /api/users/123/address If User A can update User B\u0026rsquo;s address by changing the ID, the impact becomes unauthorized state change.\nState-changing BOLA can be more severe than read-only exposure.\nExample 4: Nested Object Confusion Nested routes can hide authorization mistakes:\nGET /api/projects/project-a/files/file-b The API may check access to project-a, but forget to verify that file-b actually belongs to that project.\nA secure implementation must check the relationship between parent and child objects.\nExample 5: Batch Operations Batch APIs are common:\n{ \u0026#34;file_ids\u0026#34;: [\u0026#34;file_1\u0026#34;, \u0026#34;file_2\u0026#34;, \u0026#34;file_3\u0026#34;] } The API must authorize every object in the list, not just the request itself.\nImage: Type: PoC. Mô tả: \u0026ldquo;A controlled API lab showing two accounts and an object ID swap test. Use a mock API, PortSwigger API labs, or OWASP Juice Shop where applicable.\u0026rdquo; caption: \u0026ldquo;Object ID swap testing is the basic BOLA validation pattern.\u0026rdquo;\nHow to Test Safely Use authorized systems and test accounts only.\nA safe BOLA testing workflow:\nCreate or obtain two test users. Generate objects under User A and User B. Capture User A\u0026rsquo;s valid API request. Replace the object ID with User B\u0026rsquo;s object ID. Send the request using User A\u0026rsquo;s token. Confirm whether the API enforces object-level authorization. Repeat across read, update, delete, and action endpoints. Document the smallest safe proof. Expected secure behavior:\n403 Forbidden when the object exists but access is denied 404 Not Found when the application intentionally hides object existence No sensitive data returned No state change performed Avoid accessing real customer data. Use your own test objects whenever possible.\nBOLA vs IDOR IDOR usually describes a direct object reference that can be manipulated.\nBOLA is broader and more API-specific. It focuses on whether object-level authorization is enforced for every object access.\nIn practice:\nIDOR is a common pattern. BOLA is the authorization failure category. A UUID-based API can still have BOLA. A GraphQL API can still have BOLA. A batch endpoint can still have BOLA. The identifier format does not fix authorization.\nRemediation Strong BOLA prevention requires server-side authorization for every object access.\nRecommended controls:\nEnforce object-level authorization in the backend. Scope database queries by current user, organization, tenant, or role. Do not rely on frontend checks. Do not rely on unguessable IDs as the primary control. Centralize authorization logic where possible. Check parent-child object relationships. Authorize every object in batch operations. Use deny-by-default authorization. Add automated tests for cross-user and cross-tenant access. Log and alert on suspicious object access failures. Safer query pattern:\nSELECT invoice WHERE id = requested_id AND tenant_id = current_tenant AND user_has_permission = true The exact implementation depends on your stack, but the principle is universal:\nNever return or modify an object before verifying that the caller is allowed to access that specific object.\nPentester Notes The strongest BOLA reports include:\nTwo test accounts The original authorized request The modified object ID request Evidence of unauthorized data access or state change Clear business impact Exact affected endpoint Recommended authorization fix Do not stop after finding one endpoint. BOLA often appears as a pattern across a resource family.\nIf /api/invoices/{id} is vulnerable, check related endpoints such as download, update, export, share, delete, and batch operations.\nReferences OWASP API Security Top 10 2023 - API1: Broken Object Level Authorization: https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/ OWASP API Security Project: https://owasp.org/www-project-api-security/ PortSwigger Web Security Academy - API Testing: https://portswigger.net/web-security/api-testing CTA KevinSec helps teams test API authorization, IDOR/BOLA patterns, and multi-tenant access control. If your API exposes user, invoice, project, or organization IDs, object-level authorization should be tested before release.\n","permalink":"https://kevinsec.io/blog/api-bola-explained-with-realistic-examples/","summary":"BOLA happens when an API exposes object identifiers but fails to verify whether the caller is allowed to access the object.","title":"API BOLA Explained with Realistic Examples"},{"content":"API Broken Authentication: Common Testing Patterns API broken authentication happens when an API cannot reliably verify the identity of the caller, or when the surrounding authentication lifecycle is too weak to resist abuse.\nFor a pentester, the goal is not to \u0026ldquo;break login\u0026rdquo; only. The goal is to understand how the API issues, accepts, stores, expires, rotates, revokes, and validates authentication material.\nIn modern applications, this usually means testing:\nLogin flows Access tokens Refresh tokens API keys Session cookies MFA flows Password reset flows Mobile API authentication SSO/OAuth integrations Logout and token revocation Image: Type: Context. Mô tả: \u0026ldquo;A diagram showing a client sending credentials to an API, receiving an access token, then using that token to call protected endpoints.\u0026rdquo; caption: \u0026ldquo;API authentication is more than the login request; it includes the whole token and session lifecycle.\u0026rdquo;\nContext APIs often rely on tokens instead of traditional server-rendered web sessions.\nA simple flow may look like this:\nUser submits credentials -\u0026gt; API validates credentials -\u0026gt; API returns access token -\u0026gt; client uses token for protected API calls A protected request may look like this:\nGET /api/v1/account/profile HTTP/1.1 Host: api.example.com Authorization: Bearer \u0026lt;access_token\u0026gt; At a minimum, the API needs to answer four questions:\nIs the token valid? Who does this token represent? Is the token still allowed to be used? Is this caller authorized to perform this specific action? Broken authentication focuses mainly on the first three questions. Authorization issues such as BOLA focus on the fourth.\nRoot Cause API broken authentication usually comes from weak assumptions.\nCommon root causes include:\nThe API assumes possession of a token is always enough. Tokens do not expire, or they expire too slowly. Logout does not invalidate tokens. Refresh tokens are not rotated or revoked. Password reset or MFA flows issue tokens without proper verification. API keys are treated like permanent passwords. Authentication checks are inconsistent across endpoints. Mobile clients are trusted too much. Rate limiting is missing from authentication endpoints. Error messages expose whether a username, email, or phone number exists. Authentication is a lifecycle. Weakness in any part of the lifecycle can lead to account takeover, unauthorized API access, or long-lived session abuse.\nCommon Testing Patterns 1. Check for Missing Authentication Start by identifying protected endpoints.\nThen test whether they still respond when authentication is removed.\nSafe testing approach:\nRequest with valid token -\u0026gt; observe normal response Request without token -\u0026gt; expect 401 or 403 Request with malformed token -\u0026gt; expect rejection Request with expired token -\u0026gt; expect rejection The expected result is not always the same status code, but protected data should never be returned.\nRisky pattern:\nGET /api/v1/users/me -\u0026gt; requires token GET /api/v1/users/123 -\u0026gt; returns data without token This suggests inconsistent authentication enforcement.\nImage: Type: Test case. Mô tả: \u0026ldquo;A Burp Repeater comparison showing the same API request with Authorization header and without Authorization header, where the unauthenticated request should be rejected.\u0026rdquo; caption: \u0026ldquo;A protected API endpoint should fail closed when authentication material is missing.\u0026rdquo;\n2. Test Token Expiration Tokens should have a defined lifetime.\nCheck:\nDoes the access token expire? How long does it remain valid? Can an expired token still call protected endpoints? Does the server validate expiration or only the client? Does the API accept old tokens after password change? A frequent issue is client-side-only expiration. The frontend stops using the token, but the backend still accepts it.\nA secure API must enforce token expiration server-side.\n3. Test Logout Behavior Logout should do more than remove a token from browser storage.\nCheck:\nAfter logout, can the old access token still call the API? Is the refresh token revoked? Are server-side sessions invalidated? Are all devices logged out when the user requests it? Are active sessions visible to the user? If the API uses stateless JWT access tokens, immediate revocation may require a short token lifetime plus a server-side revocation strategy for high-risk events.\n4. Test Refresh Token Rotation Refresh tokens are high-value authentication material.\nReview:\nIs the refresh token long-lived? Is it rotated after use? Can the same refresh token be reused multiple times? Is token reuse detected? Is the refresh token bound to a device, client, or session? Is it revoked after password change or account compromise? Risky pattern:\nRefresh token issued once -\u0026gt; valid for months -\u0026gt; reusable unlimited times A stolen refresh token can become a long-term account access mechanism.\n5. Test Rate Limiting on Authentication Endpoints Authentication endpoints should be protected from high-volume abuse.\nReview rate limiting on:\nLogin MFA verification OTP verification Password reset request Password reset token validation Email change confirmation Phone number verification API key creation Token refresh Rate limiting should consider account, IP address, device, session, and risk context.\nDo not brute-force real users or production systems. In an authorized pentest, use agreed test accounts and a low-volume test plan approved in the rules of engagement.\n6. Check Account Enumeration Authentication flows often leak whether an account exists.\nExamples:\n\u0026#34;Email does not exist\u0026#34; \u0026#34;Invalid password\u0026#34; \u0026#34;This phone number is already registered\u0026#34; \u0026#34;Reset link sent\u0026#34; only for existing users Different response time for valid vs invalid accounts Enumeration is not always critical by itself, but it becomes more serious when combined with phishing, credential stuffing, password spraying, or targeted account takeover attempts.\n7. Review API Key Authentication API keys are common in developer platforms, SaaS products, and internal services.\nCheck:\nAre API keys scoped? Can users rotate keys? Can users revoke keys? Are keys shown only once? Are keys hashed at rest? Are keys logged by the application or reverse proxy? Are keys bound to environments? Can a read-only key perform write actions? An API key should be treated like a credential, not like a harmless identifier.\n8. Test MFA Flow Consistency MFA can be bypassed when it is applied inconsistently.\nReview:\nDoes API access require MFA completion? Can the user call protected API endpoints before finishing MFA? Can an old session skip newly enforced MFA? Can password reset disable MFA? Can OAuth login bypass MFA? Is MFA required for sensitive actions? A common design flaw is treating MFA as a frontend state instead of a server-side security state.\n9. Check Authentication State Transitions High-risk actions should change authentication state.\nExamples:\nPassword changed Email changed Phone number changed MFA disabled Recovery code generated New device added API key created Organization admin added After these actions, old sessions or tokens may need to be invalidated, reauthenticated, or risk-scored.\n10. Test Error Handling and Logging Authentication failures should be logged carefully.\nGood logging:\nUser identifier or account reference Source IP or device context Endpoint and event type Failed login count Token reuse signal MFA failure signal Bad logging:\nPasswords Full access tokens Full refresh tokens Password reset tokens MFA codes API keys Sensitive authentication material should never appear in logs.\nImpact API broken authentication can lead to:\nAccount takeover Unauthorized API access Data exposure Session hijacking Long-lived token abuse Privilege escalation through weak session state API key compromise Abuse of password reset and MFA flows Difficulty investigating incidents due to poor logging The impact depends on what the authenticated API can access. A weak authentication issue on a profile endpoint may be medium. The same issue on billing, admin, health records, or organization settings can be critical.\nRemediation A strong API authentication design should include:\nCentralized authentication middleware Consistent checks on every protected endpoint Short-lived access tokens Secure refresh token rotation Token revocation for logout and high-risk events Strong password reset flow MFA for sensitive accounts and actions Rate limiting on authentication endpoints Generic error messages where appropriate Secure token storage guidance for clients No sensitive token values in logs Monitoring for suspicious authentication events Pentester Checklist Use this checklist during an API pentest:\n[ ] Remove Authorization header and confirm protected endpoints reject the request [ ] Test malformed, expired, and revoked tokens [ ] Confirm logout invalidates the expected authentication state [ ] Review refresh token rotation and reuse detection [ ] Check authentication rate limiting [ ] Look for account enumeration signals [ ] Review MFA enforcement consistency [ ] Test old sessions after password or email change [ ] Review API key scope, rotation, and revocation [ ] Confirm sensitive tokens are not logged References OWASP API Security Top 10 2023 - API2 Broken Authentication: https://owasp.org/API-Security/editions/2023/en/0xa2-broken-authentication/ OWASP WSTG - Authentication Testing: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/README OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html OWASP ASVS: https://owasp.org/www-project-application-security-verification-standard/ CTA KevinSec can help review API authentication flows, token lifecycle controls, MFA enforcement, and session handling. If your product exposes APIs to web, mobile, or third-party clients, a focused authentication review can reduce account takeover risk before attackers find the gaps.\n","permalink":"https://kevinsec.io/blog/api-broken-authentication-common-testing-patterns/","summary":"API broken authentication appears when an API cannot reliably prove who the caller is or cannot safely manage credentials, tokens, and sessions.","title":"API Broken Authentication: Common Testing Patterns"},{"content":"Burp Suite Beginner Workflow for Web Pentest Burp Suite is one of the most common tools used in web application security testing.\nBeginners often learn Burp as an intercepting proxy: open browser, intercept request, modify something, send it forward.\nThat is only the first layer.\nA better workflow treats Burp as a structured testing workspace:\nBrowser traffic -\u0026gt; Proxy history -\u0026gt; Scope -\u0026gt; Repeater -\u0026gt; Notes -\u0026gt; Evidence -\u0026gt; Report Image: Type: Context. Mô tả: \u0026ldquo;A simple workflow diagram showing Browser, Burp Proxy, HTTP history, Repeater, Intruder, Logger, and final report evidence.\u0026rdquo; caption: \u0026ldquo;A clean Burp workflow turns raw traffic into reproducible security findings.\u0026rdquo;\nContext During a web pentest, Burp helps you observe, replay, modify, compare, and document HTTP traffic.\nThe core beginner tools are:\nBrowser and proxy setup Target scope Proxy HTTP history Intercept Repeater Intruder Decoder Comparer Logger Notes and issue evidence You do not need to use every feature at once. The goal is to build a repeatable workflow.\nStep 1: Configure Browser and Proxy Start by routing browser traffic through Burp.\nBasic setup:\nOpen Burp Suite. Use Burp\u0026rsquo;s embedded browser, or configure your browser proxy to Burp. Install the Burp CA certificate if testing HTTPS traffic with an external browser. Confirm traffic appears in Proxy history. Do not start testing until you can see the traffic clearly.\nIf you cannot see the request, you cannot reason about the application properly.\nStep 2: Define Scope Scope prevents noise.\nSet the target application domain as in scope.\nExample:\nhttps://app.example.com https://api.example.com Then configure Burp to show or highlight only in-scope traffic.\nThis matters because modern websites load many third-party resources: analytics scripts, fonts, CDNs, ads, identity providers, payment gateways, and support widgets.\nA clean scope helps you focus on assets you are authorized to test.\nImage: Type: Test case. Mô tả: \u0026ldquo;A Burp Target scope screen showing only app.example.com and api.example.com as in-scope assets.\u0026rdquo; caption: \u0026ldquo;Scope discipline keeps testing focused and legally clean.\u0026rdquo;\nStep 3: Browse Normally First Before attacking anything, use the application like a normal user.\nMap:\nLogin Registration Password reset Profile update Search File upload Account settings Billing Admin panel API calls Logout This creates natural traffic in Proxy history.\nDo not rush into payloads. First understand how the application is supposed to work.\nStep 4: Use Proxy History as Your Source of Truth Proxy history is where you start pattern recognition.\nLook for:\nInteresting parameters Object IDs Role or permission indicators JSON request bodies Hidden API endpoints File upload endpoints Redirect parameters Token values Cookies Custom headers GraphQL requests Different responses for different users Example patterns:\nGET /api/v1/invoices/1001 POST /api/v1/users/123/role GET /download?file=report.pdf POST /api/v1/reset-password Each request is a clue.\nA pentester\u0026rsquo;s skill is turning traffic into hypotheses.\nStep 5: Send Interesting Requests to Repeater Repeater is where manual testing becomes controlled.\nUse Repeater to:\nModify one parameter at a time Replay requests safely Compare responses Test access control Test input handling Validate assumptions Build reproduction steps Good Repeater workflow:\nOriginal request -\u0026gt; duplicate tab -\u0026gt; change one variable -\u0026gt; observe response -\u0026gt; document result Avoid changing too many things at once. If the response changes, you need to know which change caused it.\nStep 6: Use Multiple Test Accounts For access control testing, one account is not enough.\nUse at least two test users when allowed:\nUser A -\u0026gt; owns object 1001 User B -\u0026gt; owns object 2001 Admin -\u0026gt; has privileged actions Then test whether User A can access User B\u0026rsquo;s objects.\nExample workflow:\nLogin as User A -\u0026gt; capture request for User A object Login as User B -\u0026gt; capture request for User B object Replay User B object request using User A session Expected result: 403 Forbidden or equivalent denial This is essential for IDOR, BOLA, and broken access control testing.\nImage: Type: Test case. Mô tả: \u0026ldquo;Two Burp Repeater tabs comparing requests from User A and User B to test whether object-level authorization is enforced.\u0026rdquo; caption: \u0026ldquo;Access control testing requires comparing behavior across users and roles.\u0026rdquo;\nStep 7: Use Intruder Carefully Intruder can automate repeated request variations.\nBeginner-safe use cases:\nChecking a short list of known object IDs from test accounts Testing a small wordlist in a lab Comparing response lengths Testing predictable numeric parameters in an authorized environment Do not use Intruder for high-volume brute-force or aggressive scanning unless the engagement explicitly allows it.\nIn professional work, rate limits, scope, and authorization matter more than tool capability.\nStep 8: Use Decoder and Comparer Decoder helps inspect encoded values:\nBase64 URL encoding HTML encoding JWT segments Hex values Comparer helps compare responses:\nUser A vs User B Valid token vs invalid token Allowed role vs denied role Before and after modifying a parameter These tools are simple but useful for understanding subtle differences.\nStep 9: Take Notes While Testing Do not wait until the end to write notes.\nFor each interesting request, record:\nEndpoint User role Original behavior Modified request Observed response Security assumption Evidence screenshot Impact hypothesis Remediation idea Example note:\nEndpoint: GET /api/v1/invoices/{id} User: regular user Observation: invoice ID is numeric Test: User A requested User B invoice ID using User A token Result: API returned invoice data Hypothesis: BOLA / IDOR Impact: unauthorized invoice disclosure Good notes reduce report writing time.\nStep 10: Build Report Evidence For every confirmed finding, preserve:\nOriginal request Modified request Response showing impact Account context Timestamp Screenshot when useful Clear reproduction steps Evidence must be enough for the developer to reproduce the issue.\nA finding without reproducible evidence becomes a conversation. A finding with clean evidence becomes an engineering task.\nBeginner Workflow Summary [ ] Configure browser and proxy [ ] Confirm HTTPS traffic is visible [ ] Define target scope [ ] Browse the app normally [ ] Review Proxy history [ ] Identify interesting requests [ ] Send requests to Repeater [ ] Modify one variable at a time [ ] Use multiple test accounts for access control [ ] Use Intruder only when appropriate and allowed [ ] Take notes during testing [ ] Save evidence for the report Common Beginner Mistakes Mistake 1: Intercepting Everything Leaving intercept on all the time can slow testing and create confusion.\nUse intercept when needed. Use Proxy history for most review work.\nMistake 2: Testing Without Scope Without scope, Burp captures too much unrelated traffic.\nScope first. Test second.\nMistake 3: Payload First, Context Later Payloads are not a methodology.\nUnderstand the feature, role, data flow, and trust boundary before testing input.\nMistake 4: Not Saving Evidence If you cannot reproduce the issue later, you may lose the finding.\nSave clean requests and responses while testing.\nReferences PortSwigger Burp Suite Documentation: https://portswigger.net/burp/documentation PortSwigger Burp Repeater: https://portswigger.net/burp/documentation/desktop/tools/repeater PortSwigger Burp Intruder: https://portswigger.net/burp/documentation/desktop/tools/intruder OWASP Web Security Testing Guide: https://owasp.org/www-project-web-security-testing-guide/ CTA KevinSec can help teams perform structured manual web pentesting using reproducible workflows, clean evidence, and business-focused reporting. If your application needs more than a scanner output, a manual Burp-based review is a strong starting point.\n","permalink":"https://kevinsec.io/blog/burp-suite-beginner-workflow-for-web-pentest/","summary":"Burp Suite is most effective when used as a structured manual testing workspace, not just as an intercepting proxy.","title":"Burp Suite Beginner Workflow for Web Pentest"},{"content":"CORS Misconfiguration: Simple Mistake, Serious Impact Cross-Origin Resource Sharing (CORS) is often misunderstood.\nDevelopers see CORS errors in the browser and think CORS is blocking their frontend from working. They search for a quick fix, copy a permissive header, and the feature starts working. Unfortunately, that quick fix can turn into a data exposure issue.\nCORS is not an authentication mechanism. It is a browser-controlled policy that determines whether one origin is allowed to read responses from another origin.\nA safe CORS policy answers one question:\nWhich trusted origins are allowed to read this response in a browser?\nImage: Type: Context. Mô tả: \u0026ldquo;A browser diagram showing origin A attempting to read API responses from origin B, with CORS headers deciding whether access is allowed.\u0026rdquo; caption: \u0026ldquo;CORS controls browser-based cross-origin reads.\u0026rdquo;\nContext Browsers enforce the Same-Origin Policy (SOP). By default, a script running on one origin should not freely read sensitive responses from another origin.\nCORS creates a controlled exception.\nFor example, an API may return:\nAccess-Control-Allow-Origin: https://app.example.com Access-Control-Allow-Credentials: true This tells the browser that JavaScript running on https://app.example.com may read the API response, including credentialed responses if credentials are allowed.\nThe security problem appears when the API trusts origins too broadly.\nRoot Cause CORS misconfiguration usually comes from convenience:\nDevelopers want to remove browser errors quickly. The API reflects any Origin header. Wildcard origins are used without understanding the data sensitivity. Staging and production origins are mixed. Subdomain trust is too broad. Credentialed requests are enabled without strict origin validation. CORS is treated as an access control mechanism instead of a browser read policy. The most dangerous pattern is:\nUser sends Origin: https://attacker-controlled.example Server replies Access-Control-Allow-Origin: https://attacker-controlled.example Server also allows credentials If the victim is authenticated and visits a malicious page, the browser may send cookies to the API, and the malicious origin may be allowed to read the response.\nImpact CORS impact depends on what the API returns and whether credentials are involved.\nPossible impact includes:\nReading private user data from APIs Exposing account details Leaking CSRF tokens or profile data Reading internal admin data from a privileged browser session Increasing the impact of phishing or XSS chains Weakening browser isolation between trusted and untrusted origins A permissive CORS header on a public unauthenticated API may be low risk. A permissive CORS header on an authenticated API that returns sensitive user data can be high risk.\nImage: Type: Test case. Mô tả: \u0026ldquo;A Burp Suite Repeater test showing an Origin header and the API reflecting it in Access-Control-Allow-Origin. Use a lab or intentionally vulnerable environment.\u0026rdquo; caption: \u0026ldquo;Origin reflection is a common CORS misconfiguration pattern.\u0026rdquo;\nSignature Look for these response headers:\nAccess-Control-Allow-Origin: * Access-Control-Allow-Origin: https://some-origin.example Access-Control-Allow-Credentials: true Access-Control-Allow-Methods: GET, POST, PUT, DELETE Access-Control-Allow-Headers: Authorization, Content-Type Interesting signs:\nThe server reflects arbitrary Origin values. The server trusts null origins without a clear reason. The server allows credentials for too many origins. The CORS policy differs between production and staging. Sensitive authenticated endpoints return permissive CORS headers. CORS is enabled globally at the framework level. Candidate endpoints:\n/api/me /api/profile /api/account /api/users/current /api/billing /api/admin/* /graphql The best targets are endpoints that return sensitive data and rely on browser credentials.\nHow to Test Safely Only test CORS in authorized systems or labs.\nA safe testing workflow:\nFind an authenticated endpoint that returns non-public data. Send a request with a controlled Origin header. Observe whether the response includes Access-Control-Allow-Origin. Check whether the server reflects your supplied origin. Check whether Access-Control-Allow-Credentials: true is present. Confirm whether the response contains sensitive data. Avoid attempting to steal real user data; use your own test account or lab account. A strong report should show:\nThe request with the injected Origin The reflected CORS response header The sensitive response type The condition required for exploitation The exact remediation Image: Type: PoC. Mô tả: \u0026ldquo;A safe browser-based CORS lab page reading data from an intentionally vulnerable API using a test account.\u0026rdquo; caption: \u0026ldquo;A CORS PoC should use test data and prove browser-readable exposure.\u0026rdquo;\nCommon Misconfiguration Patterns 1. Reflecting Any Origin The backend reads the Origin header and returns it directly in Access-Control-Allow-Origin.\nThis is dangerous because the attacker controls the Origin value through a malicious website.\n2. Wildcard Origin on Sensitive APIs Access-Control-Allow-Origin: * may be acceptable for truly public, unauthenticated resources. It is not appropriate for sensitive authenticated APIs.\n3. Credentials with Weak Origin Validation Credentialed CORS is sensitive. If the browser sends cookies or authorization material and the API allows an untrusted origin to read the response, data exposure becomes possible.\n4. Trusting All Subdomains Trusting every subdomain may be risky if subdomain takeover, user-generated content, staging systems, or weakly controlled environments exist.\n5. Trusting null Origin The null origin can appear in special browser contexts such as sandboxed documents or local files. Trusting it should be a deliberate decision, not a default.\nRemediation Recommended defenses:\nMaintain a strict allowlist of trusted origins. Avoid reflecting arbitrary Origin values. Use exact origin matching, not loose substring matching. Do not allow credentials unless necessary. Apply CORS only to endpoints that need cross-origin browser access. Separate public APIs from authenticated sensitive APIs. Review CORS policies across staging, production, and admin surfaces. Do not rely on CORS as the only access control mechanism. Continue enforcing authentication and authorization server-side. A safer CORS decision flow:\nReceive Origin -\u0026gt; exact match against trusted allowlist -\u0026gt; set CORS headers only if matched -\u0026gt; enforce authz separately Developer Mental Model CORS does not decide who the user is. Authentication does that.\nCORS does not decide what the user can access. Authorization does that.\nCORS only decides whether a browser script from another origin can read the response.\nThat makes CORS a browser data exposure boundary, not a backend access control system.\nReferences OWASP WSTG - Testing Cross Origin Resource Sharing: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/07-Testing_Cross_Origin_Resource_Sharing PortSwigger Web Security Academy - CORS: https://portswigger.net/web-security/cors MDN Web Docs - CORS: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS CTA KevinSec can help review browser-facing APIs, CORS policies, authentication boundaries, and sensitive data exposure risks. If your frontend and API run on different origins, CORS should be part of your security review.\n","permalink":"https://kevinsec.io/blog/cors-misconfiguration-simple-mistake-serious-impact/","summary":"CORS is a browser security control for controlled cross-origin access. Misconfiguration can expose sensitive data to untrusted origins.","title":"CORS Misconfiguration: Simple Mistake, Serious Impact"},{"content":"Credential Phishing: Defensive Lessons for Employees Credential phishing is one of the most direct ways attackers gain access to business systems.\nInstead of exploiting a software vulnerability, the attacker tricks a user into giving away something that proves identity: a password, session token, MFA code, or approval response.\nThis article is written for employees and security awareness teams. It focuses on defense, not attack execution.\nImage: Type: Context. Mô tả: \u0026ldquo;A visual showing a user login screen, an MFA prompt, and a warning sign between the user and a fake login page.\u0026rdquo;. caption: \u0026ldquo;Credential phishing targets the identity layer of the organization.\u0026rdquo;\nContext Many companies rely on cloud identity providers, SaaS applications, VPN portals, email systems, customer platforms, and internal dashboards.\nThat means one compromised account can create access to many systems.\nCredential phishing is dangerous because it can lead to:\nMailbox compromise Cloud storage access Internal application access Unauthorized data download Business email compromise Lateral movement Fraudulent approvals Further phishing from a trusted account When an attacker controls a real account, their next message may look much more believable.\nRoot Cause Credential phishing succeeds when users trust a login prompt without verifying where it came from.\nCommon contributing factors include:\nPassword reuse Weak passwords Lack of MFA Push-based MFA fatigue Users typing passwords into pages reached from email links Lack of password manager adoption Lack of phishing-resistant authentication Poor reporting process Excessive access tied to normal user accounts Lack of session monitoring The problem is not only user behavior. The organization must design systems that limit damage when credentials are exposed.\nCommon Credential Phishing Scenarios Fake Login Page The user receives a message that appears to come from a known service. The link leads to a page that looks like a normal login page.\nDefensive habit:\nDo not log in through unexpected email links. Open the service directly from a trusted bookmark or official app. Use a password manager. It usually will not autofill credentials on the wrong domain. Shared Document Lure The user receives a cloud document notification and is asked to sign in to view it.\nDefensive habit:\nVerify whether the shared document is expected. Check the sender and domain. Access the document through the official cloud application. MFA Fatigue The user receives repeated MFA prompts and eventually approves one to stop the noise.\nDefensive habit:\nNever approve an MFA prompt you did not initiate. Report unexpected MFA prompts immediately. Treat repeated prompts as a potential active attack. Fake IT Support The attacker pretends to be IT and asks the user to confirm credentials, install a tool, or approve access.\nDefensive habit:\nIT should never ask for your password. Verify support requests through the official helpdesk channel. Do not move to personal chat channels for account support. Image: Type: Test case. Mô tả: \u0026ldquo;A defensive training example showing a fake cloud login prompt beside a legitimate bookmarked login flow, with the domain highlighted.\u0026rdquo;. caption: \u0026ldquo;The domain is often the difference between a legitimate login and a credential theft attempt.\u0026rdquo;\nWhat Employees Should Do Use a Password Manager Password managers help users create unique passwords and reduce password reuse.\nThey also provide a practical anti-phishing benefit: a password manager normally autofills only on the correct domain.\nIf the page looks right but the password manager does not autofill, stop and inspect the domain.\nEnable MFA MFA adds a second layer of protection when a password is stolen.\nHowever, not all MFA methods provide the same protection. Push approvals and one-time codes can still be tricked out of users in some phishing scenarios.\nFor high-risk accounts, organizations should consider phishing-resistant methods such as FIDO2/WebAuthn security keys or passkeys when appropriate.\nVerify Login Prompts Before entering credentials, ask:\nDid I initiate this login? Is this the official domain? Did I reach this page from a trusted bookmark? Is the request expected? Is my password manager recognizing the site? Report Quickly If you entered credentials into a suspicious page, report immediately.\nDo not wait to see whether something bad happens.\nFast reporting allows security teams to:\nReset passwords Revoke sessions Review login logs Disable suspicious access Check mailbox rules Investigate data access Block related domains Warn other employees What Security Teams Should Do Security teams should not treat credential phishing as a user-only problem.\nRecommended controls include:\nMFA for all important accounts Phishing-resistant MFA for privileged users Password manager adoption Conditional access policies Impossible travel detection Risk-based sign-in monitoring Session revocation capability Mailbox rule monitoring Clear phishing reporting process Safe simulations Just-in-time employee guidance Least privilege for normal accounts Remediation After Credential Entry If a user reports credential entry into a suspicious page:\nReset the password. Revoke active sessions and refresh tokens. Review recent logins. Check MFA methods for unauthorized additions. Check mailbox forwarding and inbox rules. Review cloud file access. Look for suspicious OAuth grants. Search for related phishing messages across mailboxes. Notify affected teams if needed. Capture lessons learned without blaming the reporter. Practical Takeaway Credential phishing is an identity security problem.\nEmployees can help by verifying login prompts, using password managers, refusing unexpected MFA prompts, and reporting quickly. Organizations must help by deploying strong identity controls and making safe behavior easy.\nReferences CISA: Recognize and Report Phishing NIST SP 800-63B: Authentication and Authenticator Management NIST: Phishing Resistance - Protecting the Keys to Your Kingdom FTC: How To Recognize and Avoid Phishing Scams CTA KevinSec helps organizations improve identity security awareness through practical training, phishing simulation design, and defensive reporting workflows.\nIf your team wants to reduce credential phishing risk, contact KevinSec for a focused phishing awareness and identity security review.\n","permalink":"https://kevinsec.io/blog/credential-phishing-defensive-lessons-for-employees/","summary":"Credential phishing targets passwords, sessions, and MFA workflows. Employees can reduce risk by verifying login prompts, using password managers, enabling MFA, and reporting fast.","title":"Credential Phishing: Defensive Lessons for Employees"},{"content":"CVSS for Pentesters: How to Think About Severity CVSS stands for Common Vulnerability Scoring System.\nIt provides a standardized way to describe the severity characteristics of a vulnerability.\nFor pentesters, CVSS is useful because it creates a shared language between security teams, developers, managers, auditors, and vulnerability management processes.\nBut CVSS is not a replacement for judgment.\nA good pentester should understand both:\nCVSS score -\u0026gt; standardized severity signal Business impact -\u0026gt; why the issue matters in this specific environment Image: Type: Context. Mô tả: \u0026ldquo;A severity decision diagram showing technical exploitability, affected data, affected users, privilege level, user interaction, and business context leading to final severity.\u0026rdquo; caption: \u0026ldquo;CVSS helps structure severity, but context explains why the score matters.\u0026rdquo;\nContext When a pentester reports a vulnerability, the reader wants to know priority.\nShould the team fix it today, this week, this sprint, or later?\nSeverity helps answer that question.\nCVSS considers technical characteristics such as:\nHow the vulnerability can be reached Whether privileges are required Whether user interaction is required Whether exploitation affects confidentiality, integrity, or availability Whether the impact crosses security boundaries The exact metric names depend on the CVSS version used by the organization.\nAs of CVSS v4.0, the framework includes Base metrics and additional metric groups designed to improve clarity and granularity.\nCVSS Is Not the Same as Risk This is important:\nCVSS severity is not always the same as business risk.\nCVSS describes vulnerability characteristics. Business risk also depends on:\nAsset criticality Data sensitivity Number of affected users Internet exposure Threat model Compensating controls Detection capability Regulatory requirements Business process affected Example:\nStored XSS in an internal test app -\u0026gt; lower business risk Stored XSS in an admin portal used by support staff -\u0026gt; higher business risk The technical class may be similar, but the impact context is different.\nHow Pentesters Should Think About Severity Start with these questions.\n1. Is the Vulnerability Remotely Reachable? Ask:\nIs the endpoint public? Is authentication required? Is network access restricted? Is the issue reachable from the internet? Does the attacker need internal access? Public, unauthenticated vulnerabilities usually deserve more attention than vulnerabilities requiring deep internal access.\n2. What Privileges Are Required? Ask:\nCan an anonymous user exploit it? Does the attacker need a regular account? Does the attacker need a privileged account? Can self-registration provide the required access? A vulnerability requiring admin privileges may be lower severity unless it enables privilege expansion, data exposure, or tenant compromise.\n3. Is User Interaction Required? Ask:\nDoes a victim need to click a link? Does an admin need to view a page? Does exploitation happen automatically? Is social engineering required? User interaction does not make a bug harmless, but it affects exploitability.\nExample:\nReflected XSS requiring a victim click -\u0026gt; user interaction required Stored XSS triggered when an admin opens a page -\u0026gt; user interaction likely required but impact may be high 4. What Is the Confidentiality Impact? Confidentiality means unauthorized data disclosure.\nAsk:\nCan the attacker read another user\u0026rsquo;s data? Can the attacker read sensitive internal data? Can the attacker access PII, payment data, tokens, invoices, or secrets? Is the exposure limited or broad? A BOLA issue exposing invoices across tenants can be high severity even if exploitation is technically simple.\n5. What Is the Integrity Impact? Integrity means unauthorized modification.\nAsk:\nCan the attacker change data? Can they modify another user\u0026rsquo;s profile, order, invoice, or role? Can they approve, cancel, delete, or create business records? Can they alter security settings? Unauthorized write access is often more serious than read-only exposure.\n6. What Is the Availability Impact? Availability means service disruption.\nAsk:\nCan the issue crash the application? Can it lock users out? Can it exhaust resources? Can it delete or corrupt critical data? Can it block business operations? Be careful with availability testing. Do not perform destructive or denial-of-service tests unless explicitly authorized.\nPractical Examples Example 1: Missing Security Header Issue: Missing X-Content-Type-Options header Reachability: Public Impact: Defense-in-depth weakness Business impact: Limited unless chained with content sniffing conditions Typical severity: Low / Informational depending on context This should be reported clearly but not exaggerated.\nExample 2: IDOR in Invoice API Issue: User A can access User B\u0026#39;s invoice by changing invoice_id Reachability: Authenticated regular user Impact: Cross-user billing data disclosure Business impact: Tenant isolation failure and privacy exposure Typical severity: High depending on data sensitivity and scale The issue requires authentication, but self-registration may make exploitation realistic.\nExample 3: Stored XSS in Admin Review Panel Issue: Regular user submits stored XSS that executes when admin reviews it Reachability: Authenticated user User interaction: Admin views the page Impact: Admin session actions or sensitive data exposure depending on controls Business impact: Potential account takeover chain or privileged action abuse Typical severity: Medium to High depending on exploitability and session protections User interaction exists, but the victim role increases impact.\nExample 4: Unauthenticated SQL Injection Issue: Public search endpoint is vulnerable to SQL injection Reachability: Public unauthenticated endpoint Impact: Possible data extraction or modification depending on DB permissions Business impact: Potential broad data compromise Typical severity: High to Critical depending on confirmed impact Severity should be based on confirmed or strongly evidenced impact, not only the vulnerability class name.\nImage: Type: Test case. Mô tả: \u0026ldquo;A severity comparison table showing missing header, IDOR, stored XSS, and SQL injection with reachability, privileges, user interaction, and impact columns.\u0026rdquo; caption: \u0026ldquo;Severity becomes clearer when technical characteristics are compared side by side.\u0026rdquo;\nCommon Pentester Mistakes Mistake 1: Treating Every XSS as High XSS severity depends on context:\nReflected or stored? Who triggers it? What can JavaScript access? Are cookies HttpOnly? Is CSP present? What role is affected? The vulnerability class is only the starting point.\nMistake 2: Ignoring Business Data A technically simple bug can be severe if it exposes sensitive business data.\nExample:\nGET /api/v1/payroll/{employee_id} If object-level authorization is missing, the issue may be serious even without complex exploitation.\nMistake 3: Overrating Theoretical Chains Chained impact should be plausible and evidenced.\nDo not claim full account takeover unless the steps are demonstrated or strongly supported.\nBetter wording:\nThis issue may support account takeover if combined with a separate session theft condition. Worse wording:\nThis is account takeover. Mistake 4: Reporting a Score Without a Rationale A number alone is not enough.\nExplain the main drivers:\nSeverity is High because any authenticated user can access invoices belonging to other users, the affected data includes billing information, and exploitation requires only changing a numeric object ID. A Practical Severity Workflow Use this workflow:\n1. Identify the vulnerability class 2. Confirm affected endpoint and role 3. Determine reachability 4. Determine privileges required 5. Determine user interaction 6. Confirm confidentiality, integrity, and availability impact 7. Assess business context 8. Assign severity 9. Explain rationale clearly 10. Provide remediation priority Severity Rationale Template Severity: High Rationale: The issue allows any authenticated regular user to access invoices belonging to other users by modifying the invoice_id path parameter. The exposed data includes customer billing details and invoice history. Exploitation requires no special privileges beyond a standard account and can be reproduced with a single modified API request. This breaks tenant isolation and may expose sensitive business data. This is more useful than a bare score.\nHow to Use CVSS in Reports A practical report can include:\nSeverity: High CVSS: 8.x / High Rationale: \u0026lt;plain English explanation\u0026gt; The rationale is critical because different organizations may use different CVSS versions, environmental adjustments, or internal risk frameworks.\nIf a client requires CVSS, follow their required version and scoring policy.\nIf the client does not require CVSS, still explain severity using the same thinking: reachability, privileges, user interaction, and impact.\nReferences FIRST CVSS v4.0 Specification Document: https://www.first.org/cvss/specification-document FIRST CVSS v4.0 Overview: https://www.first.org/cvss/v4.0/ NVD CVSS v4.0 Official Support: https://nvd.nist.gov/general/news/cvss-v4-0-official-support OWASP Vulnerability Management Guide: https://owasp.org/www-project-vulnerability-management-guide/ CTA KevinSec can help translate technical vulnerabilities into clear severity, business impact, and remediation priority. If your team receives scanner output but still struggles to decide what to fix first, a focused pentest report can turn findings into an actionable security roadmap.\n","permalink":"https://kevinsec.io/blog/cvss-for-pentesters-how-to-think-about-severity/","summary":"CVSS helps standardize vulnerability severity, but pentesters still need to explain exploitability, context, and business impact.","title":"CVSS for Pentesters: How to Think About Severity"},{"content":"File Upload Security: What Can Go Wrong? File upload looks like a simple feature. A user selects a file, clicks upload, and the application stores it.\nFrom a security perspective, file upload is much more complex. The application receives user-controlled content, metadata, file names, file types, file sizes, and sometimes archives or images that must be parsed by backend services.\nThat makes file upload one of the most important features to test carefully.\nImage: Type: Context. Mô tả: \u0026ldquo;A diagram showing user uploads file, application validates it, stores it, scans it, and serves it back through a download endpoint or CDN.\u0026rdquo; caption: \u0026ldquo;A secure upload flow includes validation, storage isolation, scanning, and safe retrieval.\u0026rdquo;\nContext Common upload features include:\nProfile avatar upload Resume upload Document submission Support ticket attachments Product image upload Chat file sharing Import CSV or spreadsheet Admin media library PDF invoice upload Each of these features has different business rules. A profile avatar should not accept the same file types as a document upload portal. A CSV import feature has different risks from an image upload feature.\nThe first question is not \u0026ldquo;Can I upload a payload?\u0026rdquo;\nThe first question is:\nWhat file types does the business process actually need?\nRoot Cause File upload vulnerabilities usually happen because the application trusts one or more user-controlled properties:\nFile extension Content-Type header File name File size File content Image metadata Archive structure Storage path Client-side validation Public accessibility The root cause is insufficient validation and unsafe handling of untrusted files.\nCommon Failure Patterns 1. Trusting Content-Type The Content-Type header is controlled by the client. If the server accepts files only because the request says image/jpeg, the control is weak.\nThe server should inspect the file content and enforce business-specific allowlists.\nImage: Type: PoC. Mô tả: \u0026ldquo;Burp Suite Repeater showing an upload request where Content-Type is changed in a lab environment.\u0026rdquo; caption: \u0026ldquo;Content-Type is useful metadata, not a security boundary.\u0026rdquo;\n2. Extension Blacklist Bypass Some applications block dangerous extensions using a blacklist.\nBlacklists are fragile because attackers may find alternate extensions, case variations, double extensions, or server-specific execution behavior.\nA stronger approach is to use an allowlist of permitted extensions based on business need.\n3. File Name Injection and Path Traversal If the application uses the original file name directly, a malicious file name may cause problems.\nRisks include:\nPath traversal File overwrite Log injection Header injection in downloads Unsafe rendering in HTML Confusing file names for users The application should generate server-side file names and store the original name only as metadata after safe normalization.\n4. Publicly Executable Upload Directory A high-risk pattern is storing uploaded files in a web-accessible directory where the server may execute scripts.\nEven if the upload feature is intended for images, a misconfiguration may allow server-side code execution if dangerous files are accepted and executed.\nUploaded files should be stored outside the web root or served through a controlled download handler.\n5. Missing Size Limits Large files can cause denial-of-service risk by consuming disk, memory, bandwidth, or processing time.\nThe application should enforce file size limits at multiple layers:\nReverse proxy Application server Upload handler Storage layer Background processing pipeline 6. Unsafe Image or Document Processing Many applications process uploaded files: resizing images, extracting metadata, parsing PDFs, or importing spreadsheets.\nParsers can have vulnerabilities. Even when the upload validation is correct, the processing pipeline may be exposed to malicious files.\nSecurity controls should include sandboxing, patching, and scanning where appropriate.\n7. Archive Extraction Risks Archive uploads introduce additional risks:\nZip slip/path traversal during extraction Compression bombs Nested archive bombs Unexpected file types inside archive Overwrite of existing files If archive upload is not required, do not allow it. If it is required, extract in a sandboxed environment and enforce strict limits.\n8. Insecure File Retrieval Upload security is not only about accepting files. Retrieval matters too.\nQuestions to ask:\nCan users access files uploaded by other users? Are file IDs protected by authorization checks? Are direct object references exposed? Are private files stored under public URLs? Are download links long-lived? Are file names safely encoded in responses? A secure upload feature can still become a broken access control issue if retrieval is weak.\nImpact File upload vulnerabilities can lead to:\nStored XSS Malware hosting Sensitive file exposure Account takeover through uploaded HTML/SVG in some contexts Denial of service File overwrite Server-side request or parser exploitation Remote code execution in severe misconfigurations Unauthorized access to private documents Impact depends heavily on file type, storage path, server configuration, and who can access the uploaded file.\nSignature Signals that may indicate upload risk:\nClient-side-only validation Content-Type trusted as the main control Dangerous extensions accepted Files stored under predictable public paths Original file names used directly Uploaded files served with unsafe content types Private files accessible without authorization No file size limit No antivirus or malware scanning where required Image/document processing performed without isolation Archive extraction supported without strict controls How to Test Safely Only test file upload features in authorized scope or labs.\nA safe workflow:\nIdentify allowed file types and business purpose. Test allowed files first. Check server-side validation, not only client-side validation. Inspect upload request in Burp Suite. Verify whether file extension, content type, and content are validated. Check where the file is stored and how it is served. Test whether another user can access the uploaded file. Test file size and rate limits carefully. Avoid uploading malware or destructive files. Use lab environments for high-risk scenarios. Image: Type: Test case. Mô tả: \u0026ldquo;A file upload testing checklist showing extension validation, MIME validation, file content validation, storage isolation, and access control.\u0026rdquo; caption: \u0026ldquo;Upload testing requires multiple control checks.\u0026rdquo;\nRecommended labs:\nPortSwigger file upload labs DVWA file upload module OWASP Juice Shop upload-related challenges Remediation A secure upload design should include:\nBusiness-specific file type allowlist Server-side validation File signature or content validation where appropriate Safe server-generated file names Storage outside web root No script execution in upload directories Safe download handler with authorization checks Strict file size limits Malware scanning where required Image/document processing isolation Archive extraction sandboxing Safe response headers for downloads Logging and monitoring for abnormal upload behavior For image uploads, consider re-encoding images server-side to remove dangerous metadata and normalize the file.\nFor private files, never rely only on unguessable URLs. Enforce authorization.\nReferences PortSwigger Web Security Academy: File Upload Vulnerabilities PortSwigger Lab: Web shell upload via Content-Type restriction bypass OWASP File Upload Cheat Sheet OWASP WSTG: Testing for File Upload Final Thoughts File upload is a trust boundary.\nEvery uploaded file is untrusted until the application validates it, stores it safely, processes it safely, and serves it safely.\nA mature security review should test the whole lifecycle: upload, validation, storage, processing, access control, and download.\nNeed help reviewing file upload and document handling features? KevinSec provides practical web application security testing focused on real-world upload risks, access control failures, and secure remediation.\n","permalink":"https://kevinsec.io/blog/file-upload-security-what-can-go-wrong/","summary":"File upload features are high-risk because they accept complex user-controlled content and often interact with storage, parsing, and public access paths.","title":"File Upload Security: What Can Go Wrong?"},{"content":"How to Design a Safe Phishing Simulation Program A phishing simulation program should improve security behavior, not embarrass employees.\nThe goal is not to “catch” people. The goal is to measure organizational risk, teach safer habits, and improve reporting workflows before a real attacker uses the same path.\nThis guide focuses on safe, ethical, defensive simulation design. It intentionally avoids deceptive operational detail that would help someone run unauthorized phishing.\nImage: Type: Context. Mô tả: \u0026ldquo;A program design diagram showing scope, approval, training goals, simulation scenario, reporting workflow, metrics, and lessons learned.\u0026rdquo;. caption: \u0026ldquo;A safe phishing simulation starts with governance, not with templates.\u0026rdquo;\nContext Many organizations know phishing is a risk but do not know whether employees can recognize and report suspicious messages in practice.\nA phishing simulation can help answer questions such as:\nDo employees report suspicious emails? Which departments need more support? Are users comfortable verifying urgent requests? Does the reporting process work? Are security teams able to triage reports quickly? Are high-risk roles exposed to tailored social engineering? Are existing controls reducing risk? The simulation should produce useful learning, not fear.\nCore Principles 1. Get Authorization Never run a phishing simulation without approval.\nAt minimum, define:\nExecutive sponsor Legal approval HR awareness Security owner Approved target groups Simulation window Allowed message types Data handling rules Escalation process Employee support plan If authorization is unclear, do not run the simulation.\n2. Define a Training Objective A simulation should not exist only to generate a click-rate report.\nExamples of good objectives:\nImprove reporting behavior Teach link verification Reduce credential entry risk Test MFA prompt awareness Improve suspicious attachment handling Validate incident response workflow Measure readiness of high-risk roles The scenario should match the objective.\n3. Avoid Harmful Themes Do not use emotionally harmful bait.\nAvoid simulations that exploit:\nLayoff announcements Medical emergencies Personal tragedy Payroll panic Immigration or legal fear Sensitive personal topics Public embarrassment Security training should protect trust, not damage it.\n4. Do Not Collect Real Credentials A safe simulation should never collect real passwords.\nIf a user reaches a training landing page, it should educate immediately or after a controlled interaction, depending on the approved design. The system should minimize data collection and avoid storing sensitive information.\n5. Do Not Shame Employees Do not publish names of users who clicked.\nMeasure group-level trends where possible. Use individual follow-up only when necessary and with a coaching mindset.\nThe worst outcome is employees becoming afraid to report mistakes.\nImage: Type: Funny. Mô tả: \u0026ldquo;A light meme-style illustration of a suspicious email wearing a fake mustache and holding a clipboard labeled \u0026lsquo;Urgent Request\u0026rsquo;.\u0026rdquo;. caption: \u0026ldquo;If the email is trying too hard to sound urgent, slow down.\u0026rdquo;\nProgram Design Step 1: Choose the Audience Start with a small pilot group.\nPossible groups:\nIT team Finance team HR team Sales team Executives New employees General staff High-risk teams should receive more tailored training, but the first program should be controlled and measurable.\nStep 2: Select the Scenario Type Use defensive scenario categories, not weaponized templates.\nExamples:\nSuspicious login notification Fake shared document notification Invoice approval request Password reset prompt MFA prompt awareness training QR code awareness exercise Vendor impersonation awareness Each scenario should map to one behavior you want to improve.\nStep 3: Build the Reporting Flow Before sending any simulation, ensure employees know how to report suspicious messages.\nOptions include:\nReport phishing button Security mailbox Helpdesk ticket Internal chat channel SOC triage queue A simulation without a reporting workflow measures clicks but does not build resilience.\nStep 4: Define Metrics Useful metrics include:\nReport rate Time to first report Repeat reporting behavior Click rate Credential entry simulation rate Department-level trends Training completion False positive reporting quality SOC triage time Do not over-focus on click rate. A team with high reporting can still be improving even if some users click.\nStep 5: Provide Immediate Training When users interact with a simulation, training should be short and practical.\nGood training explains:\nWhat signal was suspicious What the user should verify How to report next time Why the behavior matters What not to do in a real incident Avoid long lectures. Make the lesson specific.\nStep 6: Review Results with Context A high click rate does not automatically mean employees are careless.\nIt may indicate:\nThe scenario matched a real workflow Employees lack a clear reporting channel Processes rely too heavily on email MFA prompts are poorly understood The organization lacks verification culture Training is too generic Use results to improve systems, not blame users.\nImage: Type: Test case. Mô tả: \u0026ldquo;A sample metrics dashboard showing report rate, click rate, time to first report, and training completion by department without individual names.\u0026rdquo;. caption: \u0026ldquo;Measure resilience trends, not employee embarrassment.\u0026rdquo;\nSafety Guardrails A safe program should include:\nWritten authorization Defined scope Limited data collection No real credential capture No malware or unsafe attachments No sensitive emotional bait No public shaming Clear support channel Training landing page Post-campaign debrief Improvement plan Remediation After the Simulation After each campaign:\nSummarize results. Identify patterns. Improve reporting workflow. Update employee guidance. Strengthen technical controls. Provide targeted coaching. Share positive examples. Plan the next scenario based on observed gaps. A simulation is only valuable if it changes behavior or improves controls.\nPractical Takeaway A safe phishing simulation is a defensive exercise.\nIt should be authorized, scoped, respectful, measurable, and connected to training. The success metric is not “how many people failed.” The success metric is whether the organization becomes harder to phish after the program.\nReferences NCSC: Phishing attacks - defending your organisation CISA: Recognize and Report Phishing OWASP Application Security Awareness Campaigns NIST: Phishing Resistance - Protecting the Keys to Your Kingdom CTA KevinSec can help design phishing simulations that are safe, ethical, and useful for improving real organizational resilience.\nIf your company wants a practical phishing awareness program without shaming employees, contact KevinSec to plan a scoped simulation and training workflow.\n","permalink":"https://kevinsec.io/blog/how-to-design-a-safe-phishing-simulation-program/","summary":"A safe phishing simulation program should measure risk, teach behavior, protect employees, and avoid collecting real credentials or creating unnecessary harm.","title":"How to Design a Safe Phishing Simulation Program"},{"content":"How to Recognize a Suspicious Email A suspicious email is not always full of spelling mistakes.\nMany phishing emails look clean, professional, and business-like. Some use real logos. Some copy real notification templates. Some may even appear inside an existing email thread after an account has been compromised.\nThe goal of email security awareness is not to make employees afraid of every message. The goal is to help them recognize when a message deserves verification before action.\nImage: Type: Context. Mô tả: \u0026ldquo;A clean inbox screenshot concept with one highlighted suspicious email and callouts for sender, subject, link, attachment, and requested action.\u0026rdquo;. caption: \u0026ldquo;Suspicious email review should focus on signals, not guesswork.\u0026rdquo;\nContext Email remains one of the most common entry points for social engineering, credential theft, malware delivery, and business email compromise.\nA suspicious email usually tries to create one of three outcomes:\nMake the user click a link. Make the user open an attachment. Make the user perform a business action. The business action may be more dangerous than the link. For example, a fake invoice approval or bank account change request can create direct financial loss even without malware.\nThe Suspicious Email Checklist Use this checklist before clicking, downloading, replying, or approving anything sensitive.\n1. Check the Sender Carefully Do not rely only on the display name.\nA display name can say “IT Support” or “Finance Team” while the real email address belongs to an unrelated domain.\nLook for:\nMisspelled domains Strange subdomains Free email addresses used for business requests Unexpected external senders Display name mismatch Recently changed sender behavior Reply-to address different from the From address Example signal:\nDisplay name: Microsoft Support Actual sender: security-update@example-random-domain.com That mismatch should trigger verification.\n2. Inspect the Request Ask: what does this email want me to do?\nSuspicious actions include:\nEntering credentials Approving MFA Opening an attachment Enabling macros Downloading a file Sharing sensitive information Changing payment details Buying gift cards Moving to WhatsApp, Telegram, or personal email Ignoring normal approval workflow A message becomes high-risk when it asks for action that affects identity, money, data, or access.\n3. Watch for Urgency and Pressure Urgency is a classic social engineering trigger.\nBe careful with messages that say:\n“Immediate action required” “Your account will be suspended” “Payment deadline today” “Final warning” “Do not delay” “Respond within 10 minutes” Urgency does not prove an email is malicious. But it does mean verification matters more.\n4. Check the Link Without Clicking On desktop, hovering over a link can show the destination URL. On mobile, long-press preview behavior depends on the device and app, so be careful.\nLook for:\nDomains that do not match the expected service URL shorteners Lookalike domains Strange path names Unexpected login pages HTTP instead of HTTPS Misspelled brand names Links to file-sharing pages you did not expect Do not enter credentials into a page reached from a suspicious email. Open the official website directly from a bookmark or typed address instead.\nImage: Type: Test case. Mô tả: \u0026ldquo;A training example showing a link where the visible text says a trusted brand, but the hover preview shows a different domain.\u0026rdquo;. caption: \u0026ldquo;The visible link text and the real destination may be different.\u0026rdquo;\n5. Treat Attachments as High Risk Attachments can be used to deliver malware, steal information, or lure users into entering credentials.\nBe cautious with:\nUnexpected invoices Password-protected archives Documents asking to enable macros HTML attachments Script files Unknown file extensions Attachments from external senders Attachments that create urgency A legitimate attachment should make sense in context. If it does not, verify first.\n6. Review the Tone and Context Some suspicious emails look technically clean but feel wrong.\nExamples:\nA colleague writes in an unusual style A manager asks for secrecy A vendor changes payment details suddenly HR asks for personal documents through an unusual link IT asks for your password A cloud document appears unrelated to your work Context is a security control. If the request does not fit the relationship, verify it.\n7. Look for Business Process Violations Many serious phishing incidents succeed because the target follows an email instruction instead of the official process.\nBe cautious if the email asks you to bypass:\nPurchase approval Payment verification Vendor onboarding Identity verification Password reset process Security reporting Legal review Change management A strong company does not rely on email alone for sensitive approvals.\nWhat Not to Do Do not:\nClick just to “see what happens” Reply to the suspicious sender for verification Forward the email widely Enter fake credentials into the page Upload the attachment to random online tools Ignore the email if you already clicked Hide the mistake if you interacted with it Early reporting reduces impact.\nWhat to Do Instead If you suspect phishing:\nStop interacting with the message. Report it using the company phishing report button or security mailbox. Verify through a trusted channel if business action is required. If credentials were entered, change the password and report immediately. If MFA was approved unexpectedly, report immediately. If a file was opened, contact security immediately. Quick Rule If a message creates urgency, asks for credentials, changes money flow, requests sensitive data, or bypasses normal process, treat it as suspicious until verified.\nReferences CISA: Recognize and Report Phishing FTC: How To Recognize and Avoid Phishing Scams NCSC: Phishing attacks - defending your organisation CTA KevinSec can help your team build a simple suspicious email checklist, reporting workflow, and safe awareness training program.\nIf your employees are unsure what to report, contact KevinSec to design a phishing awareness workflow that is easy to follow in real business environments.\n","permalink":"https://kevinsec.io/blog/how-to-recognize-a-suspicious-email/","summary":"Suspicious emails can look professional. This guide shows how to inspect context, sender, links, attachments, tone, and requested actions safely.","title":"How to Recognize a Suspicious Email"},{"content":"How to Write a Professional Vulnerability Report Finding a vulnerability is only half of the work.\nThe other half is communicating it clearly.\nA professional vulnerability report should allow the reader to answer five questions:\nWhat is the issue? Where is it located? How can we reproduce it? What is the impact? How should we fix it? If the report cannot answer those questions, the finding may be technically correct but operationally weak.\nImage: Type: Context. Mô tả: \u0026ldquo;A clean vulnerability report layout showing Summary, Affected Endpoint, Steps to Reproduce, Evidence, Impact, Remediation, and References.\u0026rdquo; caption: \u0026ldquo;A strong report is structured for developers, managers, and security teams.\u0026rdquo;\nContext A vulnerability report has multiple audiences.\nDevelopers need:\nAffected endpoint Reproduction steps Expected vs actual behavior Technical root cause Remediation guidance Managers need:\nBusiness impact Severity Affected users or data Priority Risk explanation Security teams need:\nEvidence Scope Exploitability Detection opportunities Verification steps A good report serves all three without becoming confusing.\nBasic Report Structure Use this structure for most web findings:\nTitle Severity Summary Affected Asset Affected Endpoint Prerequisites Steps to Reproduce Evidence Impact Root Cause Remediation Verification Steps References Not every finding needs every section, but this structure keeps the report complete.\n1. Title The title should be specific.\nWeak title:\nAccess Control Issue Better title:\nBroken Object Level Authorization Allows Users to Access Other Users\u0026#39; Invoices A good title includes:\nVulnerability class Affected feature Main impact Examples:\nStored XSS in Profile Display Name Allows JavaScript Execution for Other Users Password Reset Token Reuse Allows Account Recovery Link Replay Missing Authorization on Invoice API Allows Cross-User Data Access 2. Severity Severity should reflect both technical exploitability and business impact.\nDo not assign severity only because a tool says so.\nConsider:\nAuthentication required or not User interaction required or not Data sensitivity Number of affected users Privilege required Business function affected Whether the issue can be chained Whether exploitation is reliable CVSS can help standardize scoring, but the explanation matters more than the number.\n3. Summary The summary should be short and clear.\nExample:\nThe invoice API does not enforce object-level authorization. A regular user can change the invoice ID in the URL and retrieve invoices belonging to other users. This may expose customer billing data, invoice history, and personally identifiable information. A strong summary avoids unnecessary jargon.\n4. Affected Asset and Endpoint Be precise.\nExample:\nAsset: https://app.example.com Endpoint: GET /api/v1/invoices/{invoice_id} Role: Authenticated regular user Environment: Production If the issue affects multiple endpoints, list them clearly.\n5. Prerequisites State what is needed to reproduce the issue.\nExamples:\n- Two regular test accounts - User A owns invoice 1001 - User B owns invoice 2001 - Valid session token for User A This prevents confusion during triage.\n6. Steps to Reproduce Steps should be deterministic.\nWeak steps:\nLogin and change the ID. Better steps:\n1. Log in as User A. 2. Open the invoice page for invoice 1001. 3. Capture the request in Burp Suite. 4. Change the invoice ID from 1001 to 2001, which belongs to User B. 5. Send the modified request. 6. Observe that the API returns User B\u0026#39;s invoice data. Each step should move the reader closer to reproduction.\nImage: Type: Test case. Mô tả: \u0026ldquo;A sanitized Burp Repeater screenshot showing an original request and modified request, with sensitive values redacted.\u0026rdquo; caption: \u0026ldquo;Good evidence should be reproducible, sanitized, and tied to clear steps.\u0026rdquo;\n7. Evidence Evidence should prove the issue without exposing unnecessary sensitive data.\nInclude:\nHTTP request HTTP response Screenshot Account context Object ownership context Redacted tokens or secrets Response difference Redact:\nAccess tokens Cookies Passwords API keys Personal data not needed for proof Customer secrets Evidence should be minimal but sufficient.\n8. Impact Impact is where many reports become weak.\nDo not write only:\nAn attacker can access sensitive data. Explain what kind of data, whose data, and why it matters.\nBetter:\nAn authenticated user can retrieve invoices belonging to other users. This may expose customer names, billing addresses, purchased services, invoice amounts, tax information, and payment-related metadata. In a multi-tenant environment, this breaks tenant isolation and may create regulatory and contractual risk. Impact should connect technical behavior to business risk.\n9. Root Cause Root cause explains why the vulnerability exists.\nExample:\nThe backend retrieves invoices by invoice_id but does not verify that the invoice belongs to the authenticated user\u0026#39;s account or organization. Authorization appears to be enforced in the frontend navigation only, not in the API endpoint itself. Root cause helps developers fix the design, not only the symptom.\n10. Remediation Remediation should be practical.\nExample:\nEnforce object-level authorization on the server side for every invoice access. The invoice lookup should be scoped to the authenticated user\u0026#39;s account or organization. If the invoice does not belong to the caller, the API should return an authorization failure and log the event for monitoring. Better remediation includes:\nServer-side control Where to apply it Expected behavior Regression test idea Avoid vague advice like:\nImplement better security. 11. Verification Steps Help the team confirm the fix.\nExample:\n1. Log in as User A. 2. Attempt to request User B\u0026#39;s invoice ID. 3. Confirm the API returns 403 Forbidden or equivalent access denial. 4. Confirm no invoice data appears in the response. 5. Repeat the test across all invoice-related endpoints. Verification steps reduce back-and-forth after remediation.\nProfessional Report Template Title: Severity: Affected Asset: Affected Endpoint: Affected Role: Summary: Steps to Reproduce: 1. 2. 3. Evidence: Impact: Root Cause: Remediation: Verification Steps: References: Common Mistakes Mistake 1: No Business Impact A report that only says \u0026ldquo;IDOR exists\u0026rdquo; is incomplete.\nExplain what the attacker can access or change.\nMistake 2: Unclear Reproduction If developers cannot reproduce the issue, the fix will be delayed.\nUse exact endpoints, roles, and steps.\nMistake 3: Too Much Sensitive Data Do not paste unnecessary personal data, full tokens, passwords, or secrets.\nProof should be controlled and sanitized.\nMistake 4: Generic Remediation Generic remediation is less useful.\nTie remediation to the vulnerable feature.\nMistake 5: Overstated Severity Exaggerated severity reduces trust.\nBe firm, but accurate.\nFinal Checklist Before submitting a report, check:\n[ ] Title is specific [ ] Severity has a clear rationale [ ] Affected endpoint is listed [ ] Reproduction steps are deterministic [ ] Evidence is sanitized [ ] Impact is business-relevant [ ] Root cause is explained [ ] Remediation is actionable [ ] Verification steps are included [ ] References are relevant References OWASP Vulnerability Management Guide: https://owasp.org/www-project-vulnerability-management-guide/ OWASP Web Security Testing Guide: https://owasp.org/www-project-web-security-testing-guide/ FIRST CVSS v4.0 Specification: https://www.first.org/cvss/specification-document CTA KevinSec provides web pentest reports that are clear, reproducible, and remediation-focused. If your team needs findings that developers can fix and managers can prioritize, a professional security report is part of the value, not just an attachment at the end.\n","permalink":"https://kevinsec.io/blog/how-to-write-a-professional-vulnerability-report/","summary":"A professional vulnerability report should help the reader understand the issue, reproduce it, assess impact, and fix it efficiently.","title":"How to Write a Professional Vulnerability Report"},{"content":"JWT Security Testing Checklist JSON Web Tokens (JWTs) are widely used in modern web applications and APIs.\nThey are compact, portable, and easy to pass between clients and services. They can also become dangerous when teams misunderstand what the token proves, how it should be validated, or where authorization decisions should live.\nA JWT is not automatically secure because it looks cryptographic.\nThe key question is:\nDoes the application validate the token correctly and enforce authorization server-side?\nImage: Type: Context. Mô tả: \u0026ldquo;A diagram showing a JWT split into header, payload, and signature, then verified by an API before returning data.\u0026rdquo; caption: \u0026ldquo;A JWT should be parsed, validated, and mapped to server-side authorization rules.\u0026rdquo;\nContext A JWT usually has three parts:\nheader.payload.signature The header describes metadata such as the signing algorithm. The payload contains claims. The signature is used to verify integrity.\nCommon claims include:\nsub - subject or user identifier iss - issuer aud - audience exp - expiration time nbf - not before iat - issued at jti - token identifier role or custom authorization claims JWTs are often used for authentication in REST APIs, Single Page Applications, mobile apps, and microservice systems.\nRoot Cause JWT vulnerabilities often come from implementation mistakes rather than JWT itself.\nCommon root causes:\nThe application accepts tokens without verifying the signature. The application allows weak or unexpected signing algorithms. The secret key is weak, leaked, reused, or hardcoded. The application does not validate issuer or audience. Expiration is missing or ignored. Sensitive authorization claims are trusted without server-side checks. Token revocation is not considered. Tokens are stored unsafely in the browser. Access tokens live too long. The dangerous assumption is:\n“If the client sends a JWT, the claims inside are true.”\nA safer assumption is:\n“Claims are only trustworthy after strict verification and must still be checked against server-side authorization rules.”\nImpact JWT implementation mistakes can lead to:\nAuthentication bypass Privilege escalation Account takeover Access to another user\u0026rsquo;s data Long-lived session compromise API abuse Broken multi-tenant boundaries Hard-to-revoke stolen tokens The impact is high when JWTs are used as the primary security boundary for APIs.\nImage: Type: Test case. Mô tả: \u0026ldquo;A Burp Suite request showing an Authorization: Bearer token header, with the token value partially blurred.\u0026rdquo; caption: \u0026ldquo;JWT testing starts by identifying where the token is used and what the API trusts.\u0026rdquo;\nJWT Security Testing Checklist 1. Identify Where JWTs Are Used Check common locations:\nAuthorization: Bearer \u0026lt;token\u0026gt; Cookie: access_token=\u0026lt;token\u0026gt; Cookie: session=\u0026lt;token\u0026gt; Also inspect:\nLocal storage Session storage JavaScript variables Mobile app traffic API documentation WebSocket connection parameters Document whether the JWT is used as an access token, ID token, refresh token, session token, or internal service token.\n2. Decode the Token Safely JWT payloads are usually Base64URL-encoded, not encrypted by default.\nDecode the token to understand claims, but do not assume the payload is confidential.\nLook for:\nUser ID Email Role Tenant ID Scope Expiration Issuer Audience Environment identifiers If sensitive data is inside a non-encrypted JWT, the issue may be information exposure even if the signature is valid.\n3. Verify Signature Enforcement The API must reject modified tokens.\nA safe test in a lab or authorized environment:\nChange a non-sensitive claim in a test token. Send the modified token. Confirm the API rejects it. Expected behavior: the server returns an authentication failure.\nIf the server accepts a modified token, signature validation is broken.\nImage: Type: PoC. Mô tả: \u0026ldquo;A lab request where a JWT claim is modified and the API correctly rejects the token. Show expected secure behavior.\u0026rdquo; caption: \u0026ldquo;Secure APIs reject tampered JWTs.\u0026rdquo;\n4. Check Algorithm Handling The server should allow only expected algorithms.\nRisk patterns include:\nAccepting unexpected algorithms Confusing symmetric and asymmetric verification Trusting the token header to decide security policy Not pinning the allowed algorithm server-side The application should not let the client decide how the token should be trusted.\n5. Check Expiration and Time Claims Review these claims:\nexp nbf iat Testing questions:\nDoes the token expire? Is the expiration reasonable? Does the API reject expired tokens? Are long-lived tokens limited to refresh flows? Is clock skew handled deliberately? Access tokens should generally be short-lived. Refresh tokens require stronger storage, rotation, and revocation logic.\n6. Validate Issuer and Audience The API should verify that the token was issued by the expected identity provider and intended for the expected application or API.\nCheck:\nIs iss validated? Is aud validated? Can a token for one API be used against another API? Can staging tokens work in production? Can tokens from another tenant be accepted? Weak issuer or audience validation is especially dangerous in SSO, OAuth, and multi-tenant systems.\n7. Test Authorization Claims Carefully Claims like role, scope, tenant, or isAdmin are sensitive.\nTesting questions:\nAre roles enforced server-side? Can role claims be modified? Is tenant isolation enforced beyond the token claim? Does the API check object ownership separately? Are scopes checked per endpoint? JWT authentication does not replace object-level authorization.\nA valid token for User A should not access User B\u0026rsquo;s objects.\n8. Check Token Revocation and Logout JWTs are often stateless, but real applications still need revocation behavior.\nCheck:\nDoes logout invalidate the token? Are refresh tokens rotated? Can old refresh tokens be reused? What happens after password change? What happens after account disablement? What happens after MFA reset? If a stolen token remains valid for too long, incident response becomes harder.\n9. Review Token Storage Browser storage affects exposure risk.\nCommon storage locations:\nCookies Local storage Session storage In-memory app state Security considerations:\nCookies should use HttpOnly, Secure, and appropriate SameSite settings. Local storage is more exposed to XSS. Mobile storage should use platform-protected storage. Tokens should not appear in URLs where they can leak through logs or referrers. 10. Check Secrets and Key Management For signed JWTs, key management is critical.\nReview:\nKey strength Key rotation Environment separation Secret leakage in repos or logs Public key trust model JWKS endpoint behavior Whether old keys remain valid longer than intended Cryptography fails when the key lifecycle fails.\nRemediation Strong JWT security requires:\nStrict signature validation Server-side algorithm allowlisting Strong secrets or keys Issuer and audience validation Short-lived access tokens Safe refresh token rotation Revocation strategy for high-risk events Secure token storage No sensitive data in plaintext payloads Server-side authorization checks per action and object Monitoring for token abuse A good design separates authentication from authorization:\nJWT proves identity and claims -\u0026gt; server verifies token -\u0026gt; server checks user permissions and object ownership -\u0026gt; API returns data The JWT should help the server make a decision. It should not replace the decision.\nReferences OWASP WSTG - Testing JSON Web Tokens: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/10-Testing_JSON_Web_Tokens OWASP JSON Web Token for Java Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html RFC 7519 - JSON Web Token: https://www.rfc-editor.org/rfc/rfc7519 CTA KevinSec can help test JWT-based authentication, API authorization, token storage, and session lifecycle controls. If your application relies on Bearer tokens, a focused JWT security review can catch high-impact mistakes early.\n","permalink":"https://kevinsec.io/blog/jwt-security-testing-checklist/","summary":"JWTs are compact signed tokens, but implementation mistakes can turn them into authentication and authorization weaknesses.","title":"JWT Security Testing Checklist"},{"content":"Legal Recon for Web Pentesting Reconnaissance is the first phase of a web pentest.\nIt is also the phase where careless testers can easily cross boundaries.\nLegal recon means collecting and analyzing information only within the approved scope, using methods allowed by the rules of engagement, and avoiding activity that could harm systems, violate privacy, or create unauthorized access.\nThe goal is simple:\nBuild enough context to test intelligently without exceeding authorization.\nImage: Type: Context. Mô tả: \u0026ldquo;A clean attack surface map showing approved domain, subdomains, web apps, API endpoints, and out-of-scope assets clearly separated.\u0026rdquo; caption: \u0026ldquo;Recon should map the attack surface, not expand beyond the authorized scope.\u0026rdquo;\nContext Before testing for vulnerabilities, a pentester needs to understand the target.\nFor web applications, that usually means identifying:\nIn-scope domains In-scope subdomains Application entry points Login flows User roles APIs Static resources Technology stack Exposed metadata Public documentation Error pages Security headers Redirect behavior Third-party integrations This does not mean scanning the whole internet. It means understanding the application surface that the client has authorized.\nScope First Legal recon begins with scope.\nBefore collecting anything, clarify:\nWhich domains are in scope? Which subdomains are in scope? Are staging, dev, and test environments allowed? Are APIs included? Are mobile backends included? Are third-party systems excluded? Are cloud buckets or CDN assets in scope? Are denial-of-service tests prohibited? Are automated scanners allowed? Are authenticated tests allowed? Are test accounts provided? What is the allowed testing window? If the rules are unclear, stop and clarify before continuing.\nA strong recon process protects both sides: the tester avoids unauthorized activity, and the client receives more precise coverage.\nPassive Recon Passive recon means collecting information without directly interacting aggressively with the target systems.\nExamples:\nReviewing the main website Reading public documentation Checking public search engine results Reviewing sitemap and robots.txt Looking at public GitHub references Reviewing public certificate transparency records Checking public DNS records Reading job descriptions for technology clues Reviewing product documentation Reviewing public API docs Passive recon is useful because it provides context with low operational risk.\nHowever, passive does not mean unrestricted. If the information leads to out-of-scope assets, keep them documented as out-of-scope and do not test them without approval.\nImage: Type: Test case. Mô tả: \u0026ldquo;A screenshot of a recon note table with columns: Asset, Source, In Scope, Technology, Notes, Risk Hypothesis.\u0026rdquo; caption: \u0026ldquo;Recon notes should separate discovered assets from approved targets.\u0026rdquo;\nActive Recon Active recon interacts with the target systems.\nExamples:\nVisiting in-scope pages Mapping application routes Fingerprinting technologies Checking HTTP headers Reviewing login and registration flows Crawling the application within rate limits Identifying API endpoints from frontend traffic Testing allowed user roles Checking publicly exposed files Active recon should be controlled, rate-limited, and consistent with the rules of engagement.\nDo not run high-volume enumeration, intrusive scans, or destructive checks unless explicitly approved.\nWhat to Collect 1. Asset Inventory Create a table of assets:\nAsset | Type | In Scope | Technology | Auth Required | Notes Example:\napp.example.com | Web app | Yes | React + API | Yes | Main customer portal api.example.com | API | Yes | JSON REST | Token | Used by web and mobile clients dev.example.com | Web app | Unknown | Unknown | Unknown | Requires scope clarification This prevents confusion later.\n2. Application Entry Points Entry points are places where untrusted data enters the system.\nExamples:\nURL path Query parameters Request body Headers Cookies File upload Search box Login form Registration form Password reset flow API endpoints WebSocket messages Entry points help the tester form vulnerability hypotheses.\n3. Authentication and Roles Document authentication context:\nAnonymous user Regular user Premium user Organization member Organization admin Support user System admin Role mapping is essential for access control testing.\nMany high-impact findings come from testing what one role can do to another role\u0026rsquo;s objects.\n4. Technology Stack Technology fingerprinting helps guide testing.\nLook for:\nFrontend framework Backend framework Server CDN or WAF API style Authentication mechanism Cloud provider clues JavaScript bundles Error message formats Third-party scripts Technology clues should inform testing, not replace it.\nDo not assume a vulnerability exists because a technology is present. Use the stack to prioritize hypotheses.\n5. Public Metadata Review public metadata carefully:\nrobots.txt sitemap.xml OpenAPI or Swagger files GraphQL endpoints JavaScript source maps Exposed .well-known paths Error pages Public documentation Public changelogs These files may reveal routes, endpoints, versions, or forgotten features.\nRecon to Hypothesis Recon becomes valuable when it creates testable hypotheses.\nWeak recon note:\nFound api.example.com Better recon note:\nFound api.example.com. Uses Bearer tokens. Multiple object IDs appear in invoice and project endpoints. Prioritize BOLA testing with two test accounts. Another example:\nPassword reset flow sends reset token by email. Prioritize token expiry, token reuse, host header handling, and account enumeration checks. The goal is not to collect endless data. The goal is to decide what to test next.\nCommon Mistakes Mistake 1: Treating Discovery as Permission Finding an asset does not mean you are allowed to test it.\nIf a subdomain appears during recon but is not in scope, document it and request clarification.\nMistake 2: Running Heavy Scans Too Early Automated scanning without context can create noise, miss logic bugs, and trigger defensive systems.\nStart with mapping and manual review. Use scanning only when allowed and when it answers a specific question.\nMistake 3: Ignoring Business Context A login page for a public marketing site and a login page for an enterprise admin portal do not carry the same business risk.\nPrioritize assets based on data sensitivity, user roles, exposure, and business criticality.\nMistake 4: Poor Notes Recon without notes is wasted effort.\nGood notes make testing faster and reporting easier.\nLegal Recon Checklist [ ] Confirm written scope and rules of engagement [ ] Separate in-scope, out-of-scope, and unclear assets [ ] Build asset inventory [ ] Identify application entry points [ ] Map authentication flows and user roles [ ] Identify API endpoints and object identifiers [ ] Review public metadata and documentation [ ] Fingerprint technology stack carefully [ ] Convert observations into vulnerability hypotheses [ ] Keep request volume reasonable and approved [ ] Escalate unclear scope before testing Remediation for Organizations Organizations can make recon safer and more effective by providing:\nClear scope Test accounts Role descriptions API documentation Testing windows Contact channel for urgent issues Rate limit expectations Out-of-scope list Known fragile systems Reporting format A pentest is more valuable when the tester spends time testing security controls, not guessing what is allowed.\nReferences OWASP WSTG - Information Gathering: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/README OWASP Web Security Testing Guide: https://owasp.org/www-project-web-security-testing-guide/ OWASP Testing Guide - Conduct Search Engine Discovery Reconnaissance for Information Leakage: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/01-Conduct_Search_Engine_Discovery_Reconnaissance_for_Information_Leakage CTA KevinSec can help organizations map their public web attack surface, identify exposed application entry points, and prioritize legal, business-focused web security testing. If your team is unsure what is exposed, start with a scoped recon review before deeper pentesting.\n","permalink":"https://kevinsec.io/blog/legal-recon-for-web-pentesting/","summary":"Legal recon is the process of mapping public information and application entry points inside an approved scope before deeper testing begins.","title":"Legal Recon for Web Pentesting"},{"content":"Lessons Learned from a Web Pentest Engagement A web pentest is not just a hunt for vulnerabilities.\nIt is a structured assessment of how an application behaves under realistic abuse cases, within an approved scope, and with enough evidence to help the client reduce risk.\nAfter several web assessments, one lesson becomes clear: the best findings are not always the most technically complex. They are the findings with clear impact, clean evidence, and practical remediation.\nImage: Type: Context. Mô tả: \u0026ldquo;A clean pentest workflow board with columns: Scope, Recon, Hypothesis, Testing, Evidence, Report, Retest.\u0026rdquo;. caption: \u0026ldquo;A professional pentest is a workflow, not a random collection of payloads.\u0026rdquo;\nLesson 1: Scope Is a Security Control Scope protects both the client and the tester.\nBefore testing, confirm:\nTarget domains Target applications API scope User roles Test accounts Allowed testing window Out-of-scope systems Restricted techniques Rate limits Data handling requirements Reporting channel A finding outside scope can create legal and operational problems even if the technical issue is real.\nGood testers document out-of-scope observations separately and ask before proceeding.\nLesson 2: Recon Quality Determines Test Quality Weak recon leads to shallow testing.\nStrong recon identifies:\nApplication flows Authentication boundaries Authorization models User roles Object identifiers API endpoints State-changing actions File upload/download paths Third-party integrations Error behavior Business-critical features The goal is not to enumerate everything blindly. The goal is to build a map of how the application works.\nA good recon note often becomes the foundation for good vulnerability hypotheses.\nLesson 3: Read the Application Like a Business Process Many important vulnerabilities are not visible from the UI alone.\nAsk business questions:\nWho should be allowed to perform this action? What object does this user own? Can this workflow be repeated? Can the order of steps be changed? Is the price calculated client-side or server-side? Can an invitation be reused? Can a role be changed indirectly? Does the system trust user-controlled fields? Business logic vulnerabilities often appear where the application assumes honest behavior.\nLesson 4: Access Control Is Everywhere Access control is not one feature.\nIt appears in every request that reads, modifies, deletes, exports, uploads, downloads, approves, or assigns something.\nTesters should check:\nHorizontal access control Vertical access control Object ownership Role transitions Admin-only actions API endpoints File access Export functions Search results Account settings Organization/team boundaries Image: Type: Test case. Mô tả: \u0026ldquo;A simple test matrix showing User A, User B, Admin, and Guest against actions such as View, Edit, Delete, Export, Invite.\u0026rdquo;. caption: \u0026ldquo;Access control testing becomes stronger when mapped as a role-action matrix.\u0026rdquo;\nLesson 5: Evidence Should Be Clean and Reproducible A vulnerability report should not force the client to guess what happened.\nGood evidence includes:\nClear affected endpoint Test account role Request and response summary Minimal reproduction steps Screenshot or sanitized request evidence Impact explanation Security control failure Remediation suggestion Avoid noisy evidence. Do not include unnecessary sensitive data. Redact tokens, cookies, personal data, and secrets.\nThe report should prove the issue without increasing data exposure.\nLesson 6: Impact Is More Important Than Payload A payload alone is not a finding.\nA useful finding explains what the vulnerability allows an attacker to do.\nFor example:\n“IDOR exists” is weak. “A normal user can download invoices belonging to other customers by changing the invoice ID” is strong. Impact should answer:\nWhat data can be accessed? What action can be performed? What privilege is bypassed? What business process is affected? What is the realistic attacker path? What is the worst credible outcome? Lesson 7: Severity Requires Context A vulnerability may look simple but have high business impact.\nSeverity depends on:\nData sensitivity Required privileges Attack complexity User interaction Exposure Business criticality Compensating controls Exploit reliability Scope of affected users Do not overstate severity, but do not understate business impact.\nLesson 8: Remediation Must Be Actionable A report should help the engineering team fix the issue.\nGood remediation is specific:\nEnforce server-side authorization checks. Validate object ownership before returning data. Use centralized access control middleware. Recheck permissions on every state-changing request. Do not trust role fields from the client. Add audit logging for sensitive actions. Add regression tests for the vulnerable workflow. Bad remediation is generic:\n“Improve security” “Sanitize input” “Use best practices” Engineers need enough detail to act.\nLesson 9: Communication Matters A pentest is a technical activity with business consequences.\nGood communication includes:\nClear status updates Early reporting for critical issues Respectful tone No unnecessary alarmism Evidence-based claims Practical remediation discussion Retest support Security work should reduce uncertainty, not create confusion.\nLesson 10: Retesting Is Part of the Value A finding is not fully closed when the report is delivered.\nRetesting confirms whether the fix works and whether the fix introduced new problems.\nA good retest checks:\nOriginal reproduction path Similar endpoints Related user roles Regression behavior Error handling Logging if relevant Retesting turns a report into risk reduction.\nPractical Takeaway A strong web pentest is structured, scoped, and evidence-driven.\nThe best testers combine technical skill with business understanding. They do not just prove that something breaks. They explain why it matters and how to fix it.\nReferences OWASP Web Security Testing Guide OWASP Application Security Verification Standard OWASP Top 10 CTA KevinSec provides practical web pentest services focused on real application risk, clean evidence, and actionable remediation.\nIf your team needs a professional web application security review, contact KevinSec to discuss scope, methodology, and deliverables.\n","permalink":"https://kevinsec.io/blog/lessons-learned-from-a-web-pentest-engagement/","summary":"A strong web pentest is not just about finding bugs. It is about understanding scope, testing logic, proving impact, and communicating risk clearly.","title":"Lessons Learned from a Web Pentest Engagement"},{"content":"Manual Testing vs Automated Scanning Automated scanning and manual testing are both useful.\nThey are not the same thing.\nA scanner can find known patterns quickly. A human tester can understand business logic, context, authorization, impact, and chained risk.\nA strong web pentest uses both:\nAutomation for breadth -\u0026gt; manual testing for depth -\u0026gt; report for business risk Image: Type: Context. Mô tả: \u0026ldquo;A split-screen illustration showing an automated scanner covering many endpoints and a manual pentester analyzing one business-critical workflow deeply.\u0026rdquo; caption: \u0026ldquo;Automation provides breadth; manual testing provides depth.\u0026rdquo;\nContext Modern web applications are too large to test fully by hand from the first minute.\nThey may contain:\nDozens of routes Hundreds of parameters Multiple user roles APIs Mobile backends Admin features Third-party integrations Hidden workflows Complex business logic Automation helps discover and check common patterns.\nManual testing helps validate whether those patterns matter and whether deeper issues exist.\nWhat Automated Scanning Does Well Automated scanners are useful for repeatable checks.\nThey can help detect:\nMissing security headers Known vulnerable components Exposed files Basic injection indicators Reflected input points TLS configuration issues Directory listing Common misconfigurations Default pages Some authentication and session weaknesses Automation is strong when the issue has a recognizable technical signature.\nExample:\nHeader missing -\u0026gt; scanner reports missing header Known vulnerable JavaScript library -\u0026gt; scanner reports component issue Reflected parameter -\u0026gt; scanner reports possible reflected XSS This is valuable because it saves time.\nWhat Automated Scanning Misses Scanners struggle when the issue requires understanding intent.\nCommon misses include:\nBroken access control BOLA / IDOR Business logic abuse Race conditions Multi-step account takeover chains Payment logic flaws Role-based permission mistakes MFA bypass through alternate flows Password reset logic weaknesses Organization or tenant isolation failures Excessive trust in frontend state A scanner may see an endpoint. It may not understand who should access it.\nImage: Type: Funny meme. Mô tả: \u0026ldquo;A meme-style image where a scanner says \u0026lsquo;No critical findings\u0026rsquo; while a pentester sees User A accessing User B\u0026rsquo;s invoice in Burp Repeater.\u0026rdquo; caption: \u0026ldquo;No scanner alert does not mean no business risk.\u0026rdquo;\nWhat Manual Testing Does Well Manual testing is strong when context matters.\nA human tester can ask:\nWhat is this feature supposed to do? Which user owns this object? Which role should perform this action? What happens if the sequence changes? What if the client modifies this hidden field? What if two requests happen at the same time? What if an old token is reused? What if a lower-privileged user calls an admin endpoint? Manual testing is not just sending payloads. It is reasoning about trust boundaries.\nExample: Access Control A scanner sees this request:\nGET /api/v1/invoices/1001 HTTP/1.1 Authorization: Bearer \u0026lt;token\u0026gt; It may not know whether invoice 1001 belongs to the current user.\nA manual tester can create two accounts and compare:\nUser A owns invoice 1001 User B owns invoice 2001 User A requests invoice 2001 Expected result: access denied If the API returns User B\u0026rsquo;s invoice to User A, that is a high-value finding.\nThis is why manual testing matters.\nExample: Business Logic Consider a coupon feature:\nApply coupon -\u0026gt; checkout -\u0026gt; remove coupon -\u0026gt; confirm payment A scanner may test parameters for injection.\nA manual tester asks:\nCan the same coupon be reused? Can the coupon make the price negative? Can the discount be changed client-side? Can two checkout requests use the same coupon at the same time? Can a user apply a coupon intended for another tenant? These are logic questions, not just input validation questions.\nWhen to Use Automated Scanning Use automation when you need:\nBroad coverage Fast baseline checks Repeated checks across environments Known vulnerability detection Header/configuration review Discovery of common files and endpoints Regression checks after fixes Supporting evidence for manual testing Automation is especially useful early in recon and later in regression testing.\nWhen to Use Manual Testing Use manual testing when you need:\nAccess control validation Authentication flow review Role comparison Business logic analysis API object ownership testing Token lifecycle review Payment or workflow testing Chained vulnerability analysis Impact validation Report-quality reproduction steps Manual testing is essential when the question is not \u0026ldquo;does this pattern exist?\u0026rdquo; but \u0026ldquo;is this behavior insecure in this business context?\u0026rdquo;\nGood Workflow A balanced workflow looks like this:\n1. Confirm scope 2. Map application manually 3. Use automation for baseline discovery 4. Review scanner results critically 5. Prioritize interesting endpoints 6. Perform manual role and logic testing 7. Validate impact 8. Write clear findings 9. Use automation again for regression checks Automation should guide manual testing, not replace it.\nScanner Output Is Not a Pentest Report A scanner report often contains:\nFalse positives Low-context warnings Duplicate issues Missing business impact Generic remediation text No clear exploit path No role context A professional vulnerability report should explain:\nWhat is vulnerable Why it is vulnerable How to reproduce it What the impact is How to fix it How to verify the fix The difference is context.\nPractical Decision Table Situation Prefer Automation Prefer Manual Testing Missing security headers Yes Optional validation Known vulnerable component Yes Validate exposure IDOR/BOLA No Yes Login brute-force controls Assistive Yes Password reset flow Assistive Yes Business logic No Yes Race condition Limited Yes Regression after fix Yes Validate manually first Report impact No Yes Common Mistakes Mistake 1: Trusting Scanner Severity Blindly Severity depends on context.\nA scanner may mark an issue medium, but business impact may make it high. The reverse is also true.\nMistake 2: Ignoring False Negatives No scanner finding does not mean the endpoint is secure.\nAccess control and logic flaws often require manual validation.\nMistake 3: Running Tools Without a Hypothesis Tools are more effective when used to answer a question.\nBetter:\nI suspect this endpoint has missing authorization. I will compare responses using two users. Worse:\nI will run everything and hope something appears. References OWASP Web Security Testing Guide: https://owasp.org/www-project-web-security-testing-guide/ PortSwigger Burp Suite Documentation: https://portswigger.net/burp/documentation OWASP Vulnerability Management Guide: https://owasp.org/www-project-vulnerability-management-guide/ CTA KevinSec combines manual web pentesting with focused automation to find issues that generic scanners miss. If your application has complex roles, APIs, or business workflows, a manual security review can provide clearer risk visibility than scanner output alone.\n","permalink":"https://kevinsec.io/blog/manual-testing-vs-automated-scanning/","summary":"Automated scanners help with coverage and speed, but manual testing is required for context, business logic, and access control validation.","title":"Manual Testing vs Automated Scanning"},{"content":"My 15-Day Content Sprint for KevinSec KevinSec is being built around a simple idea:\nTechnical trust should be demonstrated through clear, practical, and useful security work.\nA cybersecurity blog is not only a place to publish opinions. For a security consultant, it is proof-of-work. It shows how you think, how you explain risk, how you structure technical evidence, and how you communicate with developers and business stakeholders.\nThis article documents the first KevinSec content sprint: 30 blog posts in 15 days.\nImage: Type: Context. Mô tả: \u0026ldquo;A clean content sprint board showing 30 blog cards grouped into Web Security, API Security, Phishing Awareness, Methodology, and Personal Branding.\u0026rdquo;. caption: \u0026ldquo;The first KevinSec sprint focuses on building technical trust through consistent writing.\u0026rdquo;\nWhy a Content Sprint? A new security brand needs credibility.\nCredibility can come from certifications, job history, client references, public research, conference talks, tools, reports, or technical writing.\nFor KevinSec, the fastest practical path is technical writing.\nThe goals of this sprint are:\nBuild the foundation of the blog Create beginner-friendly security content Demonstrate web pentest methodology Explain common vulnerabilities clearly Publish defensive phishing awareness content Support future service pages Create material that can be reused on LinkedIn and proposals Show consistency and professionalism The target is ambitious but manageable: 30 posts in 15 days.\nThe Content Pillars The sprint is organized around five pillars.\n1. Web Security Fundamentals This pillar covers the basic thinking model behind web pentesting.\nTopics include:\nHTTP requests Untrusted data OWASP Top 10 Broken access control IDOR XSS SQL injection File upload security Path traversal SSRF CORS JWT These posts are designed for readers who want to understand the root cause, not just memorize payloads.\n2. API Security Modern applications rely heavily on APIs.\nThis pillar covers:\nBOLA Broken authentication Rate limiting Authorization mistakes Object ownership Token handling API security content is important because many real business applications expose sensitive logic through APIs.\n3. Pentest Methodology Technical findings are only valuable when they are tested, documented, and communicated professionally.\nThis pillar covers:\nLegal recon Burp Suite workflow Manual testing vs automated scanning Vulnerability reporting CVSS thinking Lessons learned from engagements This content supports KevinSec as a practical consulting brand, not only a technical blog.\n4. Phishing Awareness Phishing remains one of the most common ways attackers gain initial access.\nThe KevinSec approach to phishing content is defensive and ethical.\nTopics include:\nHow attackers abuse trust How to recognize suspicious emails Credential phishing defense Safe phishing simulation design The goal is to help organizations build awareness without shaming employees.\n5. Personal Brand and Trust A personal brand in cybersecurity should not be built on hype.\nIt should be built on useful output.\nThis sprint is part of that process: consistent publishing, clear structure, and practical guidance.\nImage: Type: Funny. Mô tả: \u0026ldquo;A light meme-style image of a security consultant surrounded by sticky notes labeled \u0026lsquo;XSS\u0026rsquo;, \u0026lsquo;IDOR\u0026rsquo;, \u0026lsquo;Report\u0026rsquo;, \u0026lsquo;CTA\u0026rsquo;, and \u0026lsquo;Publish\u0026rsquo; while holding coffee.\u0026rdquo;. caption: \u0026ldquo;Thirty posts in fifteen days is not magic. It is scope control and repeatable workflow.\u0026rdquo;\nThe Writing Template Most KevinSec technical posts follow this structure:\nContext → Root Cause → Impact → Signature → How to Test Safely → Remediation → CTA This structure keeps the writing consistent.\nIt also mirrors how a pentester should think:\nWhat is the feature doing? Where is trust being misplaced? What can an attacker gain? What signals reveal the issue? How can it be tested safely? How should it be fixed? How does the reader take the next step? Why English-First? KevinSec uses an English-first content strategy.\nThe reasons are practical:\nCybersecurity terminology is naturally English-heavy. Global clients search in English. Technical articles can support freelance proposals. LinkedIn and portfolio reuse becomes easier. Security references such as OWASP, NIST, CISA, and PortSwigger are primarily English. Vietnamese summaries can still be added when the topic is especially useful for the Vietnamese community.\nPublishing Workflow The workflow for each post is simple:\nChoose title. Define reader level. Draft using the KevinSec structure. Add image placeholders. Add references. Add CTA. Create cover image. Publish through the blog workflow. Share on LinkedIn or X. Track performance in analytics. The goal is not perfection on day one. The goal is a consistent publishing system that can improve over time.\nWhat Makes This Sprint Useful? The sprint is useful because it creates multiple assets at once:\nBlog content SEO landing material LinkedIn post ideas Client education material Training outline Future newsletter topics Internal knowledge base Proof-of-work portfolio A single article can become a LinkedIn post, a slide, a checklist, or a section in a client proposal.\nSuccess Metrics For the first 90 days, useful metrics include:\nNumber of posts published Search impressions Organic clicks Average position Most visited articles LinkedIn engagement Contact page visits Service page visits Inquiries generated Topics worth expanding Early traffic may be small. That is normal.\nThe more important early metric is consistency.\nLessons From the Sprint A few lessons are already clear:\nA blog needs structure before volume. Technical writing should be practical, not theatrical. Good titles matter. Cover images should be consistent. Every article should support a clear audience. CTA should match the topic. Writing creates clarity in your own thinking. The Next Step After the first 30 posts, KevinSec can expand into:\nResearch writeups Lab walkthroughs Vulnerability deep dives Case studies Service pages Downloadable checklists Security awareness material Interview handbook content Web pentest training modules The blog becomes the base layer for a larger security brand.\nPractical Takeaway A content sprint is not just about publishing fast.\nIt is about building a repeatable system for trust, visibility, and technical clarity.\nFor KevinSec, the first 15-day sprint is the foundation: 30 practical posts that explain web security, API risk, phishing awareness, and pentest methodology in a clear professional voice.\nCTA KevinSec is building practical cybersecurity content, web pentest services, phishing awareness training, and security consulting resources.\nIf you are looking for a security partner who communicates clearly and focuses on actionable risk reduction, contact KevinSec to start a discussion.\n","permalink":"https://kevinsec.io/blog/my-15-day-content-sprint-for-kevinsec/","summary":"This article documents the first KevinSec content sprint: 30 blog posts in 15 days, focused on building trust through practical security writing.","title":"My 15-Day Content Sprint for KevinSec"},{"content":"Password Reset Vulnerabilities: Common Patterns Password reset is one of the most sensitive features in a web application.\nIt looks simple: a user forgets a password, requests a reset link, receives a token, sets a new password, and logs in again. From a security perspective, however, password reset is an alternative authentication path. If an attacker can abuse it, they may not need the original password at all.\nA strong login page does not matter much if the recovery flow is weak.\nThis article explains common password reset vulnerability patterns from a web pentesting perspective.\nImage: Type: Context. Mô tả: \u0026ldquo;A simple flow diagram showing user requests password reset, application generates token, email is sent, user sets new password.\u0026rdquo; caption: \u0026ldquo;A password reset flow is an authentication flow with a different entry point.\u0026rdquo;\nContext A password reset flow typically includes several steps:\nThe user submits an email or username. The application checks whether the account exists. The application generates a reset token. The token is sent to the registered email address. The user opens the link and sets a new password. The application invalidates the token and updates the credential. Each step introduces a possible attack surface.\nA pentester should not only check whether the reset link works. The real question is: can an attacker influence, predict, reuse, intercept, or misdirect the recovery process?\nRoot Cause Most password reset vulnerabilities come from one of these design mistakes:\nThe application treats password reset as a support feature instead of a security-critical authentication flow. Reset tokens are weak, reusable, long-lived, or not bound to the correct account. The flow leaks whether an account exists. The application trusts user-controlled input when building the reset link. The reset process fails to invalidate old sessions or old tokens. Password policy is inconsistent between registration, password change, and password reset. In short, the application allows untrusted data or weak state management to influence account recovery.\nCommon Vulnerability Patterns 1. Account Enumeration Account enumeration occurs when the application reveals whether an email or username exists.\nFor example:\nExisting account: We sent you a reset link. Non-existing account: This email is not registered. This may look harmless, but it allows an attacker to build a list of valid users. In targeted attacks, this is useful for phishing, credential stuffing, and social engineering.\nA safer response is generic:\nIf an account exists for this email, a reset link will be sent.\nHowever, the application must also avoid side-channel leaks such as response time differences, status code differences, or different redirect behavior.\nImage: Type: Test case. Mô tả: \u0026ldquo;Two password reset responses side by side: one for an existing account and one for a non-existing account, showing why different messages leak information.\u0026rdquo; caption: \u0026ldquo;Different responses can expose valid accounts.\u0026rdquo;\n2. Weak or Predictable Reset Tokens A reset token must be cryptographically strong. If the token is short, sequential, timestamp-based, or derived from predictable user data, it may be guessable.\nExamples of weak token design include:\nIncremental numeric IDs Base64-encoded user IDs Tokens derived only from email and timestamp Short random strings Tokens generated using insecure randomness A secure reset token should be high-entropy, random, single-use, and stored server-side in a hashed form if possible.\n3. Token Reuse A reset token should become invalid immediately after use.\nIf the same token can be used multiple times, an attacker who obtains the link once may reset the password again later. This can also create confusing account recovery behavior where old emails remain dangerous.\nTest safely in a lab by using a reset link once, then attempting to reuse the same link. The expected behavior is that the second attempt fails.\n4. Long Token Expiration Password reset tokens should have a short lifetime. A token that remains valid for days or weeks increases the risk window if an email inbox is compromised or a reset link is logged somewhere.\nThere is no universal expiration time for every application, but the principle is clear: the token should be valid long enough for legitimate recovery, but not longer than necessary.\n5. Host Header Poisoning in Reset Links Some applications build password reset URLs based on request headers such as Host or X-Forwarded-Host.\nIf these headers are not validated, an attacker may be able to make the application generate a reset link pointing to an attacker-controlled domain.\nThe user receives a legitimate email from the real application, but the link may lead elsewhere.\nThis is dangerous because the attack abuses trust in the application email itself.\nImage: Type: PoC. Mô tả: \u0026ldquo;In Burp Suite Repeater, show a password reset request where the Host header is modified in a lab environment, and the generated reset link reflects the modified host.\u0026rdquo; caption: \u0026ldquo;Reset link generation must not trust user-controlled host headers.\u0026rdquo;\n6. Password Reset Token Not Bound to the Correct Account In some broken implementations, the reset token is valid but the account being updated is controlled by a parameter in the request body.\nFor example, the reset form may submit:\nPOST /reset-password token=VALID_TOKEN\u0026amp;email=victim@example.com\u0026amp;new_password=... If the application validates only the token but trusts the email parameter, the reset may apply to the wrong account.\nThe secure design is to bind the token server-side to a specific account and never trust the account identifier from the client at the final password update step.\n7. Missing Session Invalidation After a password reset, old active sessions should usually be invalidated or at least reviewed.\nIf a user resets a password because of suspected compromise, but the attacker remains logged in through an existing session, the reset has not fully solved the problem.\nFor sensitive applications, password reset should trigger:\nSession rotation Logout from other devices Notification to the user Optional review of recent login activity 8. Inconsistent Password Policy The password policy should be consistent across registration, password change, and password reset.\nA common mistake is enforcing strong passwords during registration but allowing weak passwords during password reset. This creates a downgrade path.\nThe reset flow should use the same password strength rules as the rest of the authentication system.\nImpact Password reset vulnerabilities can lead to:\nAccount enumeration Account takeover Credential stuffing support Phishing enablement Long-term unauthorized access Loss of trust in authentication controls The impact depends on the application. For a simple forum account, the risk may be moderate. For banking, SaaS admin panels, healthcare, or internal enterprise portals, the impact can be critical.\nSignature Look for these signals during testing:\nDifferent response messages for valid and invalid accounts Reset tokens that are short or predictable Reset links that remain valid after use Reset links that stay valid for too long Reset URLs reflecting the Host header Reset form containing editable user identifiers Password reset does not invalidate existing sessions Password policy weaker than registration or password change No notification after password reset How to Test Safely Only test password reset flows in applications where you have authorization.\nA safe test approach:\nCreate two test accounts that you control. Request password reset for account A. Observe the reset email, token structure, expiration, and link format. Try to reuse the token after a successful reset. Check whether account identifiers can be modified. Test whether the response leaks account existence. Check whether old sessions remain valid after reset. Confirm whether password policy is consistent. Do not test against real user accounts unless the scope explicitly allows it.\nImage: Type: Test case. Mô tả: \u0026ldquo;A checklist table for password reset testing with columns: test case, expected secure behavior, result.\u0026rdquo; caption: \u0026ldquo;Password reset testing should be structured and controlled.\u0026rdquo;\nRemediation A secure password reset flow should include:\nGeneric responses for reset requests Strong random reset tokens Short token expiration Single-use tokens Server-side token-to-account binding No trust in user-controlled account identifiers Validated canonical domain for reset links Consistent password policy Session invalidation after reset User notification after successful password reset Logging and monitoring for abnormal reset attempts References OWASP Forgot Password Cheat Sheet OWASP Authentication Cheat Sheet OWASP WSTG: Testing for Weak Password Change or Reset Functionalities Final Thoughts Password reset is not a secondary feature. It is a second door into the account.\nIf that door is weak, attackers do not need to break the main login flow.\nA mature security review should always include password reset testing as part of authentication testing.\nNeed help reviewing your authentication and account recovery flows? KevinSec provides practical web application security reviews focused on real-world account takeover risks, authentication weaknesses, and business-impact findings.\n","permalink":"https://kevinsec.io/blog/password-reset-vulnerabilities-common-patterns/","summary":"Password reset is an account recovery feature, but small design flaws can turn it into an account takeover path.","title":"Password Reset Vulnerabilities: Common Patterns"},{"content":"Path Traversal and LFI: Reading Files You Should Not Read Path traversal and Local File Inclusion (LFI) are classic web security issues, but they still appear in modern applications because file handling is everywhere.\nA web application may allow users to download invoices, view profile images, read documents, import templates, render pages, or load language files. These features look harmless. The risk appears when the application uses user-controlled input to decide which file should be read, included, or returned.\nFrom a pentester\u0026rsquo;s point of view, this is the key question:\nCan untrusted data influence a server-side file path?\nIf the answer is yes, the application needs strong validation, canonicalization, and authorization checks.\nImage: Type: Context. Mô tả: \u0026ldquo;A diagram showing a browser sending a request with a file parameter to a web server, and the server reading a file from the filesystem.\u0026rdquo; caption: \u0026ldquo;Path traversal starts when user input becomes part of a server-side file path.\u0026rdquo;\nContext A typical file-related endpoint may look like this:\nGET /download?file=invoice-2026.pdf HTTP/1.1 Host: example.com Cookie: session=... The expected behavior is simple: the user downloads a legitimate invoice.\nThe vulnerable behavior appears when the backend builds a path like this:\n/uploads/invoices/ + user_input If user_input is trusted too much, an attacker may try to move outside the intended directory and reach files that should never be accessible from the web application.\nPath traversal is commonly associated with reading files. LFI is closely related but often involves including or executing a local file through an application-level include mechanism. The impact depends heavily on the technology stack and how the file is processed.\nRoot Cause The root cause is usually one of these mistakes:\nThe application concatenates user input directly into a file path. The application only checks whether the input looks like a filename, but does not resolve the final path. The application uses blocklists instead of allowlists. The application does not enforce that the resolved path stays inside the intended base directory. The application assumes hidden parameters, database values, or server-side references are always safe. The application performs authorization on the page, but not on the file object. The simplest mental model is:\nA file path is a security decision. Treat it like authorization logic, not string formatting.\nImpact The impact can range from low to critical depending on what the application can access.\nPossible outcomes include:\nReading application source code Reading configuration files Exposing credentials or API keys Accessing private user files Accessing logs Disclosing internal paths and framework details In some technology stacks, chaining into remote code execution A finding becomes more severe when the accessed file contains secrets, session material, customer data, cloud credentials, or internal system configuration.\nImage: Type: Test case. Mô tả: \u0026ldquo;A lab screenshot showing a download endpoint where a file parameter is being tested in Burp Suite Repeater. Sensitive values should be blurred.\u0026rdquo; caption: \u0026ldquo;A safe lab test should prove path control without exposing real sensitive data.\u0026rdquo;\nSignature A path traversal or LFI candidate often appears in these places:\nfile= path= download= template= page= view= lang= theme= document= image= attachment= Example request patterns:\nGET /download?file=report.pdf HTTP/1.1 GET /image?name=avatar.png HTTP/1.1 GET /render?template=invoice.html HTTP/1.1 GET /docs/view?path=user-guide.pdf HTTP/1.1 The interesting part is not only the parameter name. The real signal is whether the response suggests that the backend is reading from the filesystem.\nLook for:\nFile content returned directly Different errors for existing vs non-existing files Server-side stack traces mentioning paths Response headers such as Content-Disposition File metadata in the response Different response size when changing the filename How to Test Safely Test only in systems where you have authorization, such as PortSwigger Web Security Academy, DVWA, OWASP Juice Shop, or an approved pentest scope.\nA safe testing workflow:\nIdentify endpoints that read or download files. Confirm the normal behavior with a legitimate file. Change the filename to another allowed file and observe the response. Test whether the application accepts path-like input. Check whether the final file is restricted to the intended directory. Avoid accessing real secrets or production-sensitive files unless your rules of engagement explicitly allow it. Document the minimum proof needed to show the control failure. A good pentest report does not need to dump sensitive files. It needs to prove that access control on file paths is broken.\nImage: Type: PoC. Mô tả: \u0026ldquo;A PortSwigger path traversal lab with Burp Suite showing the vulnerable request and the successful lab completion banner. Do not include sensitive real-world files.\u0026rdquo; caption: \u0026ldquo;Use intentionally vulnerable labs to demonstrate the pattern safely.\u0026rdquo;\nCommon Mistakes in Fixes 1. Removing Only One Pattern Some fixes only remove one traversal pattern. This is fragile because path handling can vary by operating system, framework, encoding, and proxy layer.\nA stronger fix is to resolve the final path and verify that it remains inside an approved base directory.\n2. Trusting File Extensions Checking that a filename ends in .pdf or .jpg is not sufficient. Extension validation does not prove that the final resolved path is safe, nor does it prove that the current user is allowed to access that file.\n3. Using Blocklists Blocklists are easy to bypass and hard to maintain. Use an allowlist of known file IDs, database references, or server-generated object identifiers instead.\n4. Forgetting Authorization Even if path traversal is fixed, the application may still allow one user to download another user\u0026rsquo;s file by changing an object reference.\nThat becomes an access control issue, often related to IDOR or BOLA.\nRemediation Strong defenses include:\nUse server-side file IDs instead of user-controlled file paths. Store file metadata in a database and map IDs to server-controlled paths. Enforce authorization on every file access. Normalize and canonicalize paths before access. Verify that the resolved path stays inside the intended directory. Avoid passing user input into file include functions. Use allowlists for file types and storage locations. Store uploaded files outside the web root when possible. Return generic errors that do not leak internal paths. Monitor abnormal file access patterns. A safer design is:\nUser requests: /download?id=12345 Server checks: Does this user own file 12345? Server resolves: Internal trusted file path from database Server returns: File only if authorization succeeds This separates user input from filesystem control.\nPentester Notes When testing path traversal and LFI, focus on the data flow:\nrequest parameter -\u0026gt; backend variable -\u0026gt; path construction -\u0026gt; file read/include -\u0026gt; response If you can influence the path, ask three questions:\nCan I move outside the intended directory? Can I access a file that belongs to another user? Can the file content expose secrets or enable a higher-impact chain? The best findings are not just “path traversal exists.” The best findings explain what security boundary failed and what business impact follows.\nReferences OWASP WSTG - Testing Directory Traversal File Include: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/01-Testing_Directory_Traversal_File_Include OWASP WSTG - Testing for File Inclusion: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_File_Inclusion PortSwigger Web Security Academy - Path Traversal: https://portswigger.net/web-security/file-path-traversal CTA KevinSec helps teams review file handling, upload/download workflows, and access control logic before attackers find weak paths. If your application serves user files, documents, reports, or media, consider a focused web security review.\n","permalink":"https://kevinsec.io/blog/path-traversal-and-lfi-reading-files-you-should-not-read/","summary":"Path traversal and LFI happen when applications let untrusted input influence file paths or file inclusion behavior.","title":"Path Traversal and LFI: Reading Files You Should Not Read"},{"content":"Phishing Awareness: How Attackers Abuse Trust Phishing is often described as a fake email that tricks someone into clicking a link.\nThat description is correct, but incomplete.\nAt its core, phishing is a trust-abuse technique. The attacker does not need to defeat a firewall first. They try to influence a person into trusting a message, a link, an attachment, a login page, or an instruction that should have been questioned.\nA mature phishing awareness program should not teach employees to be paranoid about every message. It should teach them to slow down when a message creates pressure, bypasses normal process, or asks for sensitive action.\nImage: Type: Context. Mô tả: \u0026ldquo;A simple visual showing a suspicious email in the center, surrounded by four trust-abuse triggers: urgency, authority, familiarity, and reward.\u0026rdquo;. caption: \u0026ldquo;Most phishing attempts manipulate trust signals before asking for action.\u0026rdquo;\nContext Modern organizations rely heavily on email, chat, cloud applications, shared documents, and identity providers. That creates a large human-facing attack surface.\nEmployees receive routine messages every day:\nPassword reset notifications Invoice approvals Document sharing links HR updates Login prompts MFA requests Vendor messages Customer support tickets Cloud file invitations Delivery notifications Attackers abuse this normal workflow. Their goal is to make a malicious request look like something the user already expects to see.\nThis is why phishing is not limited to email. It can happen through SMS, voice calls, messaging apps, social media, fake support portals, collaboration tools, and QR codes.\nRoot Cause The root cause is misplaced trust.\nUsers often trust a message because it appears to match one or more familiar signals:\nA known brand name A familiar sender display name A realistic logo A business-like tone A routine workflow A shared file notification A login page that looks normal An urgent deadline A message that appears to come from a manager The technical weakness is rarely just the email itself. It is the combination of weak identity verification, poor reporting habits, insufficient MFA, password reuse, excessive user privileges, and business processes that allow sensitive actions to be triggered by messages alone.\nA phishing-resistant organization reduces the number of actions that can be performed only because a message asked for them.\nCommon Trust-Abuse Patterns Urgency Urgency pushes users to act before thinking.\nExamples include:\n“Your account will be suspended today” “Payment must be approved immediately” “You missed a security update” “Confirm this login within 10 minutes” The defensive habit is simple: urgent messages deserve slower verification, not faster obedience.\nAuthority Attackers often pretend to be someone with power: CEO, CFO, HR, IT support, legal team, or a trusted vendor.\nAuthority works because people are trained to respond quickly to senior staff and important business functions.\nA good organization protects employees by making it acceptable to verify sensitive requests through a second channel.\nFamiliarity Familiarity lowers suspicion.\nA message may imitate:\nA real colleague A real supplier A real SaaS platform A real internal workflow A real project name The more the message resembles normal work, the more dangerous it becomes.\nReward Some phishing messages promise something useful:\nBonus information Shared documents Job opportunities Refunds Discounts Event invitations Account upgrades The hook is not always fear. Sometimes it is curiosity or benefit.\nConfusion Confusion is also useful to attackers.\nIf a message is vague but appears important, users may click just to understand what is happening.\nA suspicious message does not have to be obviously malicious. It only needs to create enough uncertainty that the user takes the next step.\nImpact Successful phishing can lead to:\nCredential theft Session compromise Malware execution Unauthorized mailbox access Business email compromise Fraudulent payment approval Data exposure Account takeover MFA fatigue Cloud application access Lateral movement inside the organization The first click is rarely the final impact. It is usually the entry point into a larger attack chain.\nThis is why phishing awareness should be connected to identity security, endpoint security, logging, and incident response.\nDefensive Signals to Watch A message should be treated with caution when it asks the user to:\nEnter a password after clicking a link Approve an MFA prompt they did not initiate Download and open an unexpected file Enable macros or bypass browser warnings Transfer money or change bank details Share confidential information Move conversation to a personal channel Act outside normal business workflow Keep the request secret Ignore standard approval process Image: Type: Test case. Mô tả: \u0026ldquo;A training screenshot of a sample suspicious email with callouts highlighting sender mismatch, urgent language, external link, and unusual request.\u0026rdquo;. caption: \u0026ldquo;Effective awareness training teaches users to identify patterns, not memorize every possible phishing email.\u0026rdquo;\nHow to Respond Safely When a message looks suspicious:\nDo not click links or open attachments. Verify the request using a trusted channel. Report the message using the company reporting process. Do not forward the message to many people unless instructed. If credentials were entered, report immediately. If an MFA prompt was approved by mistake, report immediately. If a file was opened, disconnect from sensitive systems and contact security. The response process should be easy. If reporting is complicated, users will avoid it.\nRemediation and Prevention A phishing-aware organization should combine user behavior, technical control, and process design.\nRecommended controls include:\nSecurity awareness training Safe phishing simulations Clear reporting button or mailbox MFA for important accounts Phishing-resistant authentication for high-risk users Password managers Email filtering Attachment sandboxing Domain monitoring DMARC, DKIM, and SPF Least privilege access Conditional access policies Login anomaly detection Playbooks for suspected credential compromise Training alone is not enough. The environment should make safe behavior easy and risky behavior difficult.\nPractical Takeaway Phishing works because it targets trust, routine, and pressure.\nThe best defense is not to blame users. The best defense is to build verification habits, resilient identity controls, and reporting workflows that make suspicious messages easier to stop.\nReferences NCSC: Phishing attacks - defending your organisation CISA: Recognize and Report Phishing FTC: How To Recognize and Avoid Phishing Scams NIST: Phishing Resistance - Protecting the Keys to Your Kingdom CTA KevinSec helps teams turn phishing awareness into practical defensive behavior through safe simulations, employee training, and actionable reporting workflows.\nIf your organization wants to improve phishing resilience without shaming employees, contact KevinSec for a practical security awareness review.\n","permalink":"https://kevinsec.io/blog/phishing-awareness-how-attackers-abuse-trust/","summary":"Phishing is not only a technical problem. It is a trust-abuse problem that targets human habits, business processes, and weak verification culture.","title":"Phishing Awareness: How Attackers Abuse Trust"},{"content":"Rate Limiting: The Control That Many Apps Forget Rate limiting is one of the most practical security controls in web applications and APIs.\nIt is also one of the controls teams forget until something goes wrong.\nA login endpoint works. OTP works. Password reset works. Search works. File upload works. The API returns data correctly. But no one asks:\nHow many times can a client repeat this action?\nThat question is where rate limiting starts.\nImage: Type: Context. Mô tả: \u0026ldquo;A diagram showing many client requests entering an API gateway, with a rate limiter allowing normal traffic and slowing abusive traffic.\u0026rdquo; caption: \u0026ldquo;Rate limiting protects business logic, infrastructure, and users.\u0026rdquo;\nContext Rate limiting controls how often a client can perform an action within a defined time window.\nIt can apply to:\nIP address User account Session API key Device fingerprint Tenant Endpoint Business action Security-sensitive actions include:\nLogin attempts Password reset requests OTP validation MFA challenge creation Email verification Username availability checks Coupon redemption Search and export features File upload Expensive API queries AI or third-party integration calls Rate limiting is not just about stopping denial-of-service attacks. It also prevents brute force, enumeration, automation abuse, and cost amplification.\nRoot Cause Rate limiting failures usually happen because applications are built around happy paths.\nDevelopers test:\nCan the user log in? Can the user request an OTP? Can the user search data? Can the user call the API? Pentesters ask:\nCan the user repeat the action 1,000 times? Can the action be automated? Can the limit be bypassed by changing IP, account, session, or header? Can the feature create cost or load for the business? Common root causes:\nNo limit exists. The limit exists only per IP address. The limit resets too quickly. The limit can be bypassed by changing headers. Different endpoints share the same sensitive action but not the same limit. The application limits requests but not expensive operations. There is no monitoring for abuse patterns. Impact Missing rate limiting can lead to:\nCredential stuffing Password brute force OTP brute force Account enumeration Email or SMS bombing Coupon abuse Resource exhaustion API scraping Increased cloud or third-party service costs Denial of service Abuse of AI or compute-heavy features In OWASP API Security Top 10 2023, resource consumption is treated as a major API security risk because satisfying API requests consumes CPU, memory, bandwidth, storage, and sometimes paid third-party services.\nImage: Type: Test case. Mô tả: \u0026ldquo;A lab chart showing repeated requests to an OTP verification endpoint and the expected secure response after a limit is reached.\u0026rdquo; caption: \u0026ldquo;Security-sensitive actions should become harder to repeat, not easier to automate.\u0026rdquo;\nSignature Look for endpoints where repetition changes risk:\nPOST /login POST /api/auth/login POST /forgot-password POST /reset-password/request POST /otp/verify POST /mfa/challenge POST /email/verify GET /api/search?q=... POST /api/export POST /api/upload POST /api/invite POST /api/coupon/apply Potential signs of weak rate limiting:\nNo delay after many failed attempts Same response speed after repeated failures No lockout or progressive throttling Limit only applies to one endpoint variant Limit can be bypassed by changing IP-like headers Limit does not apply across accounts or sessions No user notification for suspicious attempts No audit trail How to Test Safely Rate limit testing must be controlled. Do not stress production systems or send high-volume traffic unless explicitly authorized.\nA safe workflow:\nConfirm the endpoint and action sensitivity. Use a test account. Send a small, controlled number of repeated requests. Observe whether throttling, lockout, or delay appears. Test whether the limit is per account, per IP, per session, or per action. Stop before causing service degradation. Document the minimum evidence required. For public blog content, use labs, staging environments, or local applications to demonstrate the concept.\nImage: Type: PoC. Mô tả: \u0026ldquo;A Burp Suite Intruder or Repeater-based lab test showing a low-volume sequence of failed OTP attempts and the absence or presence of throttling.\u0026rdquo; caption: \u0026ldquo;Rate limit testing should be controlled and low volume unless explicitly authorized.\u0026rdquo;\nWhere Rate Limiting Matters Most 1. Login Login endpoints need protection against brute force and credential stuffing.\nRecommended controls:\nPer-account throttling Per-IP throttling Progressive delays Suspicious login detection MFA for risky events Credential stuffing monitoring 2. OTP and MFA OTP verification is especially sensitive because codes are short by design.\nControls should include:\nStrict attempt limits per code Expiration Single-use verification Per-account and per-session limits Resend limits Notification on suspicious activity 3. Password Reset Password reset can be abused for account enumeration, email flooding, or token brute force.\nControls should include:\nGeneric responses Request throttling Per-account cooldowns Token attempt limits Monitoring for repeated recovery attempts 4. Search and Export Search and export endpoints can be abused for data scraping or resource exhaustion.\nControls should include:\nPagination limits Query cost limits Export size limits Per-user quotas Async job limits Monitoring for unusual patterns 5. Paid or Third-Party Integrations Endpoints that trigger SMS, email, AI inference, payment checks, or external API calls can generate real costs.\nControls should include:\nQuotas Budget thresholds Tenant-level limits Abuse alerts Circuit breakers Common Bypass Patterns A rate limit is weak if it only checks one signal.\nCommon bypass ideas to defend against:\nRotating IP addresses Changing sessions Changing accounts Changing case or encoding Switching endpoint versions Using mobile vs web API variants Abusing batch endpoints Adding misleading forwarding headers The fix is not to block every trick individually. The fix is to model the business action and enforce limits at the right layer.\nRemediation Strong rate limiting should be layered:\nPer IP Per account Per session Per API key Per tenant Per endpoint Per business action Per resource cost Additional controls:\nProgressive throttling Temporary lockout for high-risk actions CAPTCHA only where appropriate Monitoring and alerting Abuse analytics Clear user messaging Safe defaults at API gateway and application layers A practical policy example:\nOTP verification: 5 attempts per code, 10 attempts per account per hour, resend cooldown, alert on suspicious attempts The exact numbers depend on the business, but the principle is fixed: repeated sensitive actions must have boundaries.\nReferences OWASP API Security Top 10 2023 - API4: Unrestricted Resource Consumption: https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/ OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html OWASP Forgot Password Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html CTA KevinSec can help test login, OTP, password reset, API, and resource-heavy features for abuse resistance. If a feature can be repeated, it needs a security-focused rate limit review.\n","permalink":"https://kevinsec.io/blog/rate-limiting-the-control-that-many-apps-forget/","summary":"Rate limiting is not only a performance control. It is a security boundary for authentication, abuse prevention, and API resource protection.","title":"Rate Limiting: The Control That Many Apps Forget"},{"content":"Reflected XSS Explained: Context, Root Cause, Impact Cross-site scripting, usually called XSS, is one of the classic web security vulnerabilities. It has existed for decades, but it still appears in modern applications because the root cause is simple: untrusted data reaches the browser in an unsafe context.\nReflected XSS is often the first XSS variant that beginners learn because it is easy to understand. The application receives input from the request and immediately reflects it in the response.\nIf the application does not encode or sanitize the data correctly, the browser may interpret attacker-controlled input as executable code.\nImage: Type: Context. Mô tả: \u0026ldquo;A simple diagram showing browser sends search query to server, server reflects the query in HTML response, browser renders it.\u0026rdquo; caption: \u0026ldquo;Reflected XSS occurs in the request-response cycle.\u0026rdquo;\nContext Imagine a search page:\n/search?q=laptop The application displays:\n\u0026lt;p\u0026gt;You searched for: laptop\u0026lt;/p\u0026gt; This is normal behavior. The application receives the value laptop and shows it back to the user.\nThe problem begins when the application reflects arbitrary input without safe output encoding.\nA reflected XSS vulnerability means the attacker does not permanently store the payload on the server. Instead, the victim is tricked into opening a crafted URL or submitting a crafted request. The response then contains the unsafe reflected input.\nThis is why reflected XSS is often associated with malicious links, phishing, or social engineering.\nRoot Cause The root cause of reflected XSS is not \u0026ldquo;JavaScript exists.\u0026rdquo; The root cause is unsafe handling of untrusted data.\nMore precisely:\nThe application receives data from an HTTP request. The application inserts that data into the HTML response. The data is inserted into a browser-executable context. The application fails to apply context-aware output encoding. The key phrase is context-aware.\nEncoding for an HTML body is different from encoding for an HTML attribute, JavaScript string, URL parameter, or CSS context. A defense that works in one context may fail in another.\nImage: Type: Test case. Mô tả: \u0026ldquo;A page showing user input reflected inside HTML body, HTML attribute, JavaScript string, and URL context.\u0026rdquo; caption: \u0026ldquo;XSS testing starts by identifying the reflection context.\u0026rdquo;\nCommon Reflection Contexts HTML Body Context Example:\n\u0026lt;p\u0026gt;You searched for: USER_INPUT\u0026lt;/p\u0026gt; This is the most basic context. If user input is placed directly into HTML, the application must encode characters that can change the document structure.\nHTML Attribute Context Example:\n\u0026lt;input value=\u0026#34;USER_INPUT\u0026#34;\u0026gt; Attribute context is different. Quotes, spaces, and event handler attributes may become relevant.\nJavaScript Context Example:\n\u0026lt;script\u0026gt; var search = \u0026#34;USER_INPUT\u0026#34;; \u0026lt;/script\u0026gt; This is more dangerous because user input is placed directly inside a script block. The application must safely serialize data into JavaScript, not simply escape a few characters.\nURL Context Example:\n\u0026lt;a href=\u0026#34;USER_INPUT\u0026#34;\u0026gt;Continue\u0026lt;/a\u0026gt; URL context requires strict validation of allowed schemes and destinations. Encoding alone may not be sufficient.\nImpact The impact of reflected XSS depends on what the vulnerable application allows the attacker to do in the victim\u0026rsquo;s browser.\nPossible impacts include:\nPerforming actions as the victim Reading sensitive data visible to the victim Modifying page content Capturing user input in the vulnerable page Bypassing weak CSRF assumptions Delivering phishing content from a trusted domain Escalating impact when combined with admin sessions or weak session controls Reflected XSS is sometimes dismissed as \u0026ldquo;just alert(1).\u0026rdquo; That is a mistake.\nThe real impact is not the alert box. The real impact is attacker-controlled JavaScript executing in the origin of the vulnerable application.\nSignature Signals that may indicate reflected XSS:\nUser input appears in the immediate HTTP response. Special characters are not encoded. Input is reflected inside HTML, attributes, scripts, or URLs. The application modifies input but still allows context breaking. Reflected input appears in error messages, search pages, redirect pages, or debug output. The behavior changes when special characters are submitted. Common places to inspect:\nSearch parameters Error messages Login failure messages Redirect parameters Tracking parameters Form fields User profile preview pages Support ticket preview pages How to Test Safely Only test reflected XSS in authorized systems or labs such as PortSwigger Web Security Academy, DVWA, or OWASP Juice Shop.\nA safe workflow:\nFind input that is reflected in the response. Identify the exact context where the input appears. Test harmless markers first, such as a unique string. Check whether special characters are encoded. Use a safe proof-of-concept only in lab or authorized scope. Document the request, response, reflection context, and impact. Image: Type: PoC. Mô tả: \u0026ldquo;Burp Suite Repeater showing a lab request with a search parameter and the reflected value highlighted in the HTML response.\u0026rdquo; caption: \u0026ldquo;Before testing payloads, confirm where the input is reflected.\u0026rdquo;\nFor learning, a good starting point is the PortSwigger reflected XSS lab path. Use it to understand context, not to memorize payloads.\nRemediation Effective remediation depends on the output context.\nGeneral defensive controls include:\nUse context-aware output encoding. Avoid inserting untrusted data into dangerous contexts. Use safe templating frameworks correctly. Validate input where business rules are known. Apply Content Security Policy as a defense-in-depth layer. Avoid dangerous DOM APIs for client-side rendering. Keep security controls server-side where possible. Do not rely on blacklists. For HTML output, encode HTML special characters. For JavaScript output, use safe serialization. For URL output, validate allowed schemes and destinations.\nThe safest strategy is to avoid building HTML or JavaScript through string concatenation.\nReferences PortSwigger Web Security Academy: Reflected XSS PortSwigger Web Security Academy: XSS Contexts PortSwigger Web Security Academy: Cross-site scripting OWASP Cross Site Scripting Prevention Cheat Sheet Final Thoughts Reflected XSS is not just about making JavaScript run. It is about understanding how user-controlled data moves from the request into the browser.\nThe pentester\u0026rsquo;s job is to identify the context, prove the risk safely, and explain the real business impact.\nNeed help identifying XSS and client-side security issues in your web application? KevinSec provides practical web pentest services focused on root cause, reproducible evidence, and remediation that developers can apply.\n","permalink":"https://kevinsec.io/blog/reflected-xss-explained-context-root-cause-impact/","summary":"Reflected XSS happens when user-controlled input is returned in an immediate response without safe output handling.","title":"Reflected XSS Explained: Context, Root Cause, Impact"},{"content":"SQL Injection Lab: From Error Message to Root Cause When beginners learn SQL injection, they often focus on payloads. A better approach is to focus on reasoning.\nA SQL error message is not the vulnerability itself. It is evidence that the application may be passing user-controlled input into a database query unsafely.\nThis lab-style article explains how to move from an error message to root cause analysis.\nUse this workflow only in authorized labs such as PortSwigger Web Security Academy, DVWA, OWASP Juice Shop, or an application where you have explicit permission.\nImage: Type: Lab. Mô tả: \u0026ldquo;A PortSwigger Web Security Academy SQL injection lab page with a product category filter visible.\u0026rdquo; caption: \u0026ldquo;A lab environment is the right place to practice SQL injection reasoning.\u0026rdquo;\nContext A common SQL injection lab pattern is a product category filter.\nThe application has a URL like:\n/filter?category=Gifts When the user selects a category, the application retrieves matching products from the database.\nA simplified backend query may look conceptually like this:\nSELECT * FROM products WHERE category = \u0026#39;Gifts\u0026#39; If the application builds this query with string concatenation, the category parameter may affect the SQL structure.\nStep 1: Establish the Baseline Before testing anything, capture a normal request and response.\nQuestions to answer:\nWhat parameter controls the product list? What does a normal response look like? How many products are shown? Does the response include error messages? Does the parameter appear to be text, number, UUID, or enum? This baseline matters because SQL injection testing is comparative. You need to know what \u0026ldquo;normal\u0026rdquo; looks like before identifying abnormal behavior.\nImage: Type: Test case. Mô tả: \u0026ldquo;Burp Suite Repeater showing a normal category filter request and a normal HTTP 200 response.\u0026rdquo; caption: \u0026ldquo;Always capture a clean baseline before testing.\u0026rdquo;\nStep 2: Send a Minimal Probe The next step is not to use a complex payload. The next step is to send a minimal probe that may break query syntax in a controlled way.\nFor example, in a lab, a single quote character may produce a database error if the application inserts the value inside a quoted SQL string.\nThe goal is not exploitation. The goal is signal.\nIf the response changes significantly or shows a database error, you may have evidence of unsafe query construction.\nStep 3: Read the Error Message Carefully A database error may reveal:\nThe database type The query context Whether input is inside a string Whether the application exposes verbose backend errors Whether the error is generated by the database or application layer However, do not overclaim.\nA database error is a clue. It is not yet a complete impact demonstration.\nA good pentester asks:\nWhat does this error tell me about how the application handles input?\nImage: Type: PoC. Mô tả: \u0026ldquo;A lab response showing a SQL syntax error after submitting a minimal probe in the category parameter.\u0026rdquo; caption: \u0026ldquo;The error message points to unsafe query construction.\u0026rdquo;\nStep 4: Form the Root Cause Hypothesis Based on the error, a likely root cause may be:\nThe application concatenates the category parameter directly into a SQL query without parameterization.\nThis hypothesis should be tested carefully in the lab.\nYou are trying to prove that the parameter can change the database query logic, not merely that an error appears.\nStep 5: Confirm Query Influence Safely In a controlled lab, you can compare responses that should produce different logical outcomes.\nFor example:\nA baseline request returns normal products. A modified request changes the condition. The product list changes in a way that matches query logic manipulation. The exact test depends on the lab and database context.\nDo not use destructive SQL statements. Avoid actions that modify, delete, or damage data unless the lab explicitly requires it.\nStep 6: Document the Finding A useful vulnerability report should include:\nAffected endpoint Affected parameter Normal request and response Minimal test request and response Evidence of database error or query logic manipulation Root cause explanation Business impact Remediation recommendation A weak report says:\nSQL injection found.\nA strong report says:\nThe category parameter appears to be concatenated into a SQL query without parameterization. A minimal syntax-breaking input causes a database error, and controlled boolean-style tests change the product result set. This indicates that untrusted input can alter the query structure.\nRoot Cause The root cause is unsafe query construction.\nThe application likely builds a SQL statement using user-controlled input directly. This allows input to escape the intended data context and modify query logic.\nThe correct fix is not to block a single character. The correct fix is to separate data from query structure.\nImpact Depending on the application and database permissions, SQL injection may allow:\nUnauthorized data access Authentication bypass Data modification Data deletion Sensitive information exposure Privilege escalation through application logic In some cases, deeper system compromise For a beginner lab, the goal is not to exaggerate. The goal is to understand the path from parameter to database query.\nSignature Useful testing signals:\nDatabase error after minimal syntax probe Different response body when logical conditions change Different number of records returned Delayed response during time-based checks in blind contexts Parameters that map to filters, IDs, search, sorting, or reports Verbose backend error messages Safe Lab Sources Recommended lab sources:\nPortSwigger Web Security Academy SQL injection labs DVWA SQL injection module OWASP Juice Shop injection challenges Image: Type: Test case. Mô tả: \u0026ldquo;A three-row table showing baseline request, minimal probe request, and controlled confirmation request in a lab.\u0026rdquo; caption: \u0026ldquo;Good testing moves from baseline to signal to confirmation.\u0026rdquo;\nRemediation Recommended fixes:\nUse parameterized queries or prepared statements. Avoid dynamic query construction with string concatenation. Use allowlists for dynamic identifiers such as sort fields. Apply least privilege to database users. Disable verbose database errors in production. Add automated tests for injection cases. Review ORM usage for unsafe raw query patterns. Log and monitor abnormal query-related errors. References PortSwigger Web Security Academy: SQL Injection PortSwigger Lab: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data OWASP SQL Injection Prevention Cheat Sheet OWASP WSTG: Testing for SQL Injection Final Thoughts SQL injection testing should be evidence-driven.\nStart with the baseline. Trigger a minimal signal. Confirm query influence safely. Then explain the root cause in a way developers can fix.\nThat is the difference between running payloads and performing professional web security testing.\nNeed help validating SQL injection and other injection risks safely? KevinSec provides structured web application security testing with clear reproduction steps, practical impact assessment, and remediation guidance.\n","permalink":"https://kevinsec.io/blog/sql-injection-lab-from-error-message-to-root-cause/","summary":"A SQL error message is not the vulnerability itself. It is a clue that the application may be building queries unsafely.","title":"SQL Injection Lab: From Error Message to Root Cause"},{"content":"SQL Injection: What Actually Happens Behind the Query SQL injection is one of the most important web vulnerabilities to understand because it teaches a fundamental security lesson:\nUser input must remain data. It must not become code or query structure.\nA web application often receives input from a user, builds a database query, sends that query to the database, and displays the result. SQL injection occurs when untrusted input is inserted into the query in a way that changes what the database executes.\nThis article explains what actually happens behind the query.\nImage: Type: Context. Mô tả: \u0026ldquo;A flow diagram showing browser input, web application builds SQL query, database executes query, result returns to browser.\u0026rdquo; caption: \u0026ldquo;SQL injection happens between input handling and query execution.\u0026rdquo;\nContext Consider a product search feature:\n/search?category=books The application may query the database for products in the selected category.\nA safe application treats books as data. An unsafe application may concatenate it directly into a SQL string.\nThe problem is not the database itself. The problem is how the application constructs the query.\nRoot Cause The root cause of SQL injection is unsafe query construction.\nA vulnerable pattern looks like this conceptually:\nquery = \u0026#34;SELECT * FROM products WHERE category = \u0026#39;\u0026#34; + user_input + \u0026#34;\u0026#39;\u0026#34; If the user input is normal, the query behaves as expected.\nBut if the input contains SQL syntax, the database may interpret part of the input as query logic.\nThat is the core issue: the boundary between data and query structure is broken.\nData vs Query Structure A database query has structure:\nSELECT * FROM products WHERE category = \u0026#39;books\u0026#39; In this query:\nSELECT defines the operation. products is the table. WHERE defines a condition. 'books' is data. The application should allow the user to influence only the data portion, not the structure.\nWhen SQL injection occurs, user-controlled input changes the structure. It may alter conditions, add logic, change ordering, trigger errors, or access data outside the intended query.\nWhat the Database Sees From the database\u0026rsquo;s perspective, it receives one final SQL statement.\nThe database does not know which parts came from the developer and which parts came from the user. It simply parses and executes the query.\nThat is why the application must enforce the boundary before sending the query.\nImage: Type: Test case. Mô tả: \u0026ldquo;A split view showing intended query construction on the left and unsafe string-concatenated query on the right.\u0026rdquo; caption: \u0026ldquo;The database executes the final query string, not the developer\u0026rsquo;s intention.\u0026rdquo;\nCommon SQL Injection Locations SQL injection can appear in many places, not only login forms.\nCommon locations include:\nSearch fields Category filters Product IDs User profile IDs Sorting parameters Report filters Admin panels API query parameters Authentication forms Export functions Analytics dashboards Any parameter that influences a database query is worth reviewing.\nTypes of SQL Injection Error-Based SQL Injection The application returns database errors that reveal query structure or database behavior.\nThis is often easier to identify because the response contains visible clues.\nUnion-Based SQL Injection The attacker attempts to combine results from another query into the original response.\nThis depends on the query context and response rendering.\nBoolean-Based Blind SQL Injection The application does not show database errors or query results directly, but the response changes based on true or false conditions.\nTime-Based Blind SQL Injection The response does not visibly change, but the database can be made to delay its response under certain conditions.\nThis is slower and noisier, but still important in high-value targets.\nImpact SQL injection can have serious impact:\nReading unauthorized data Bypassing authentication Modifying database records Deleting data Accessing sensitive information Escalating to administrative functions In some environments, reaching operating system-level impact The real impact depends on database permissions, application architecture, network segmentation, and exposed data.\nA well-written report should avoid vague statements like \u0026ldquo;SQLi leads to database compromise\u0026rdquo; unless the evidence supports it. Instead, explain exactly what data or action is affected in the tested context.\nSignature Signals that may indicate SQL injection:\nDatabase error messages Different response behavior for special characters Unexpected changes in result count Boolean behavior changes Delayed responses linked to input SQL keywords affecting behavior Parameters that directly control filtering, sorting, or lookup Numeric IDs accepted without validation API filters that map directly to database queries How to Test Safely Only test SQL injection in authorized systems or labs.\nA safe testing workflow:\nIdentify parameters likely to affect database queries. Send harmless baseline requests. Observe normal response behavior. Introduce minimal test characters in authorized scope. Compare response differences. Avoid destructive actions. Prove impact with the least intrusive method. Document request, response, affected parameter, and business impact. Image: Type: PoC. Mô tả: \u0026ldquo;Burp Suite Repeater showing a lab product category request and a database error after a minimal test character is submitted.\u0026rdquo; caption: \u0026ldquo;A minimal test case can reveal unsafe query construction.\u0026rdquo;\nFor learning, use PortSwigger SQL injection labs rather than testing random public websites.\nRemediation The primary defense is parameterized queries, also called prepared statements.\nParameterized queries separate query structure from user-supplied data. The database receives the query structure and parameter values separately, preventing user input from becoming executable SQL logic.\nAdditional defenses:\nUse safe ORM patterns correctly. Avoid string concatenation for queries. Validate input based on business rules. Use allowlists for sorting and column names. Apply least privilege to database accounts. Disable verbose database errors in production. Monitor unusual query behavior. Add automated tests for injection-prone paths. Input validation alone is not enough. It is useful, but it should not replace parameterized queries.\nReferences PortSwigger Web Security Academy: SQL Injection PortSwigger Web Security Academy: Blind SQL Injection OWASP SQL Injection Prevention Cheat Sheet OWASP WSTG: Testing for SQL Injection Final Thoughts SQL injection is not about memorizing payloads. It is about understanding how user input crosses into a database query.\nOnce you understand the boundary between data and query structure, SQL injection becomes much easier to reason about.\nNeed help reviewing injection risks in your web application or API? KevinSec provides practical web pentest services focused on root cause analysis, safe validation, and clear remediation guidance.\n","permalink":"https://kevinsec.io/blog/sql-injection-what-actually-happens-behind-the-query/","summary":"SQL injection happens when untrusted input becomes part of a database query structure instead of remaining data.","title":"SQL Injection: What Actually Happens Behind the Query"},{"content":"SSRF Explained for Developers and Pentesters Server-Side Request Forgery (SSRF) is a vulnerability where an attacker can influence a server-side application to send a request to an unintended destination.\nThis matters because the server often has network access that the attacker does not have. It may reach internal services, cloud infrastructure, private APIs, admin panels, or trusted network zones. The attacker does not directly connect to those systems. The vulnerable application connects on their behalf.\nThe core idea is simple:\nSSRF happens when untrusted input controls where the server sends a request.\nImage: Type: Context. Mô tả: \u0026ldquo;A diagram showing an attacker controlling a URL parameter, the web server making the request, and the target being an internal or external service.\u0026rdquo; caption: \u0026ldquo;In SSRF, the vulnerable server becomes the request origin.\u0026rdquo;\nContext Modern applications frequently fetch remote resources:\nImporting an image from a URL Generating a preview from a link Calling a webhook Fetching metadata from an integration Downloading a document from cloud storage Validating an external callback URL Proxying a request through a backend service Example feature:\nPOST /api/preview HTTP/1.1 Host: example.com Content-Type: application/json { \u0026#34;url\u0026#34;: \u0026#34;https://example-cdn.com/image.png\u0026#34; } Expected behavior: the server fetches the image and generates a preview.\nVulnerable behavior: the user-controlled url can point somewhere the application should never access.\nRoot Cause SSRF usually appears because developers focus on functionality:\n“The user gives us a URL, then our server fetches it.”\nThe missing security question is:\n“Which destinations is this server allowed to reach?”\nCommon root causes include:\nUser-controlled URLs are fetched without strict validation. The application only checks the URL format, not the resolved destination. The application allows redirects to untrusted destinations. The backend has broad network access. Internal services trust requests from the application server. Cloud or infrastructure metadata services are reachable from the application runtime. The application has no egress filtering. SSRF is not only an input validation issue. It is also a network trust and architecture issue.\nImpact SSRF impact depends on what the vulnerable server can reach.\nPossible impact includes:\nInternal service discovery Access to internal-only admin panels Reading internal API responses Reaching cloud metadata services Leaking credentials or tokens Triggering actions on internal systems Bypassing network controls Pivoting into deeper application logic Some SSRF findings are low impact if the server can only fetch public resources and responses are not returned. Other SSRF findings become critical when the server can access sensitive internal services or secrets.\nImage: Type: Test case. Mô tả: \u0026ldquo;A lab environment showing an SSRF request in Burp Suite Repeater and a controlled internal test service responding. Use PortSwigger SSRF labs or a private test service.\u0026rdquo; caption: \u0026ldquo;SSRF testing should use controlled lab targets, not unauthorized internal systems.\u0026rdquo;\nSignature Look for endpoints that accept URLs, domains, webhooks, callbacks, or remote resource references.\nInteresting parameter names include:\nurl uri link target endpoint callback webhook redirect_uri avatar_url image_url feed next Interesting features include:\nLink preview generators PDF generators Image importers Webhook configuration pages OAuth or SSO callback settings Integrations with Slack, Jira, GitHub, or cloud services Server-side proxy endpoints XML parsers that fetch external resources Response clues may include:\nThe application returns the fetched content. The response time changes based on the destination. Error messages reveal DNS, connection, or HTTP client behavior. The application follows redirects. A collaborator-style server receives a request from the target backend. How to Test Safely Only test SSRF in authorized scopes or labs. Good safe options include PortSwigger Web Security Academy, private test services, and approved internal lab environments.\nA safe workflow:\nIdentify features that accept a URL or remote endpoint. Use a domain you control or a collaborator endpoint to confirm whether the server makes an outbound request. Observe source IP, headers, HTTP method, and timing. Test whether redirects are followed in a controlled way. Avoid probing real internal networks unless the rules of engagement explicitly allow it. Document the request flow and explain what the server can reach. The goal is not to scan internal networks through the server. The goal is to prove that destination control is not constrained.\nImage: Type: PoC. Mô tả: \u0026ldquo;A safe collaborator-style callback showing that the target server made an outbound HTTP request to a controlled domain. Blur target identifiers if needed.\u0026rdquo; caption: \u0026ldquo;A controlled callback is usually enough to prove server-side request behavior.\u0026rdquo;\nCommon Variants 1. Basic SSRF The application fetches a URL supplied by the user and returns the response.\nThis is the easiest variant to identify because the response body may reveal what the server fetched.\n2. Blind SSRF The application makes the request, but the response is not returned to the user.\nThis is common in webhook validation, PDF generation, analytics, and asynchronous job systems. Detection often requires a controlled external endpoint.\n3. SSRF via Redirect The application validates the first URL but follows a redirect to a different destination.\nDevelopers often forget that validation must apply to the final destination after redirects, not only the initial input.\n4. SSRF Through File or Media Processing Some libraries fetch external resources while processing HTML, XML, images, or documents. The vulnerable input may not look like a URL parameter at first.\nRemediation Strong SSRF prevention combines application controls and network controls.\nApplication-level defenses:\nUse allowlists for approved destination domains. Avoid arbitrary URL fetching when possible. Validate scheme, host, port, and resolved IP. Re-validate after redirects. Block access to private, loopback, link-local, and internal address ranges when not explicitly required. Do not return raw internal responses to users. Set strict timeouts and response size limits. Use dedicated fetcher services with narrow permissions. Network-level defenses:\nApply egress filtering. Restrict backend access to internal services. Segment sensitive infrastructure. Require authentication between internal services. Harden cloud metadata access where applicable. Monitor unusual outbound traffic from application servers. A mature defense assumes input validation may fail and limits what the server can reach anyway.\nDeveloper Mental Model Do not treat SSRF as merely “bad URL validation.” Treat it as untrusted routing control.\nA safer design is:\nUser selects an approved integration -\u0026gt; server maps it to a trusted endpoint -\u0026gt; outbound request is made with strict egress policy An unsafe design is:\nUser submits any URL -\u0026gt; server fetches it from a privileged network position That difference is the heart of SSRF prevention.\nReferences OWASP Server-Side Request Forgery Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html OWASP Top 10 2021 - Server-Side Request Forgery: https://owasp.org/Top10/2021/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/ PortSwigger Web Security Academy - SSRF: https://portswigger.net/web-security/ssrf CTA KevinSec can help review URL-fetching features, webhook integrations, PDF generators, and backend service trust boundaries. If your application accepts external URLs, it deserves a focused SSRF review before production exposure.\n","permalink":"https://kevinsec.io/blog/ssrf-explained-for-developers-and-pentesters/","summary":"SSRF happens when a web application can be tricked into making server-side requests to unintended locations.","title":"SSRF Explained for Developers and Pentesters"},{"content":"Stored XSS vs Reflected XSS: Practical Differences Stored XSS and reflected XSS are both forms of cross-site scripting. In both cases, attacker-controlled input reaches the browser and is interpreted as executable script in the context of the vulnerable application.\nThe difference is where the payload lives and how the victim receives it.\nReflected XSS is returned immediately in a response. Stored XSS is saved by the application and delivered later to users who view the affected page.\nThis difference changes exploitability, impact, detection, and remediation priority.\nImage: Type: Context. Mô tả: \u0026ldquo;Side-by-side diagram: reflected XSS travels through a crafted URL and immediate response; stored XSS is saved in database and later rendered to another user.\u0026rdquo; caption: \u0026ldquo;The key difference is persistence.\u0026rdquo;\nReflected XSS in Practice Reflected XSS occurs when the application takes input from the current HTTP request and includes it in the immediate response unsafely.\nExample locations:\nSearch result pages Error messages Redirect pages Form validation messages Debug output Tracking parameters The attacker usually needs to deliver a crafted link or request to the victim. This often requires social engineering, phishing, or another delivery channel.\nReflected XSS is still important because the JavaScript executes under the trusted origin of the vulnerable website.\nStored XSS in Practice Stored XSS occurs when the application saves attacker-controlled input and later renders it unsafely to other users.\nExample locations:\nComments User profiles Support tickets Product reviews Chat messages CMS pages Admin dashboards File names or metadata Audit logs Stored XSS is usually more severe because the attacker does not need to send a crafted link to every victim. The application itself becomes the delivery mechanism.\nIf an admin views a stored payload in an internal dashboard, the impact may increase significantly.\nImage: Type: PoC. Mô tả: \u0026ldquo;A lab comment field where input is submitted, stored, and then rendered on the blog post page for another user.\u0026rdquo; caption: \u0026ldquo;Stored XSS becomes dangerous when untrusted data is rendered repeatedly.\u0026rdquo;\nRoot Cause The root cause is the same for both types:\nUntrusted data is rendered in a browser context without proper context-aware output encoding.\nThe difference is the data path.\nReflected XSS Data Path Request parameter → Server response → Browser execution Stored XSS Data Path Request body → Database/storage → Later page render → Browser execution Stored XSS often crosses more trust boundaries. The application may validate input at creation time but forget to encode it at display time. This is a common design mistake.\nImpact Comparison Factor Reflected XSS Stored XSS Persistence Not persistent Persistent Delivery Usually crafted link/request Application page itself Victim interaction Victim often opens a crafted link Victim views affected page Typical severity Medium to high High to critical Common locations Search, error, redirect Comments, profiles, admin panels Business risk Phishing, session abuse, action abuse Mass impact, admin compromise, workflow compromise The impact is not determined only by the XSS type. It also depends on:\nWho can trigger the payload Who views the affected page What privileges the viewer has Whether sensitive data is accessible in the page Whether actions can be performed from the victim context Whether CSP and cookie flags reduce exploitation options Why Stored XSS Often Gets Higher Priority Stored XSS is usually easier to weaponize because the attacker can place the payload once and wait.\nFor example:\nAttacker submits a malicious comment. Moderator opens the admin review page. The payload executes in the moderator\u0026rsquo;s browser. The attacker may perform actions available to the moderator. Even if the application has limited public impact, stored XSS in admin-facing workflows can be serious.\nImage: Type: Test case. Mô tả: \u0026ldquo;A support ticket system where a user-submitted message is rendered in an admin dashboard.\u0026rdquo; caption: \u0026ldquo;Admin-facing stored XSS can increase severity.\u0026rdquo;\nWhy Reflected XSS Still Matters Reflected XSS is sometimes underestimated because it requires a delivery step.\nHowever, it can still be high impact when:\nThe vulnerable domain is trusted by users. The application has sensitive authenticated pages. The payload can perform actions as the victim. The application lacks strong CSRF protections. The vulnerable page is used by privileged users. The attack can be chained with open redirect, phishing, or weak session controls. Reflected XSS can also be easier to discover at scale because many parameters are reflected in immediate responses.\nSignature Reflected XSS Signals Input appears in the immediate response. Reflection happens through query parameters. Error/search/redirect pages display user input. Payload is not stored after the request ends. Stored XSS Signals Input is submitted once and appears later. The payload appears for other users. The issue is tied to comments, profiles, tickets, reviews, or admin panels. The affected page may be different from the input page. How to Test Safely Use authorized labs such as PortSwigger Web Security Academy, DVWA, or OWASP Juice Shop.\nFor reflected XSS:\nSubmit a unique marker in a request parameter. Check the immediate response. Identify the output context. Test safely with lab-only payloads. For stored XSS:\nSubmit a unique marker in a field that is stored. Visit pages where the data appears later. Test with another account if authorization allows. Check whether the data appears in admin or moderation views. Confirm the output context. Document the full data path. Image: Type: Test case. Mô tả: \u0026ldquo;Two-browser test setup: attacker account submits input, victim/test admin account views rendered content.\u0026rdquo; caption: \u0026ldquo;Stored XSS testing often requires checking cross-user rendering.\u0026rdquo;\nRemediation Both stored and reflected XSS require context-aware output encoding.\nAdditional controls:\nValidate input based on business rules. Encode output based on rendering context. Sanitize rich-text HTML with a proven library. Avoid dangerous DOM APIs. Use safe templating engines correctly. Apply CSP as defense-in-depth. Treat admin dashboards as high-risk rendering surfaces. Do not rely on blacklists or simple string replacement. For stored XSS, remediation must also include cleaning existing stored data if malicious content may already exist.\nReferences PortSwigger Web Security Academy: Cross-site scripting PortSwigger Web Security Academy: Reflected XSS PortSwigger Web Security Academy: XSS Contexts OWASP Cross Site Scripting Prevention Cheat Sheet Final Thoughts Stored XSS and reflected XSS are not just labels. They describe how untrusted data travels through the application.\nA strong pentest report should explain the data path, execution context, affected users, and business impact.\nThat is what turns an XSS finding from a payload screenshot into a useful security issue.\nNeed help testing stored and reflected XSS in your application? KevinSec provides practical web application security testing with clear evidence, impact analysis, and developer-focused remediation guidance.\n","permalink":"https://kevinsec.io/blog/stored-xss-vs-reflected-xss-practical-differences/","summary":"Stored and reflected XSS share the same browser-side risk, but they differ in persistence, delivery, and business impact.","title":"Stored XSS vs Reflected XSS: Practical Differences"},{"content":"Authentication Testing Checklist for Web Applications Authentication is one of the most important security controls in a web application. It answers a basic question:\nIs this user really who they claim to be?\nA weak authentication flow can lead to account takeover, credential stuffing, session abuse, password reset compromise, MFA bypass, and unauthorized access to sensitive data.\nThis article provides a practical checklist for testing authentication in authorized web application security assessments.\nImage: Type: Context, Mô tả: \u0026ldquo;A diagram showing common authentication flows: registration, login, MFA, password reset, session creation, logout, and account recovery.\u0026rdquo;. caption: \u0026ldquo;Authentication testing should cover the full identity lifecycle, not only the login form.\u0026rdquo;\nScope of Authentication Testing Authentication testing should cover more than username and password validation.\nReview:\nRegistration Login Password policy Password reset Email change MFA Session management Logout Account recovery Rate limiting Error messages OAuth/SSO if applicable Logging and alerting A secure login page does not guarantee a secure authentication system. Many account takeover vulnerabilities appear in recovery and account management flows.\n1. Registration Testing Check whether registration can be abused.\nQuestions:\nCan users register with duplicate emails? Is email verification required? Can disposable or malformed emails be used? Can users set privileged fields during registration? Does the system allow mass registration without rate limiting? Are invitation-only flows enforced server-side? Can username/email enumeration happen during registration? Potential issues:\nAccount enumeration Mass account creation Role manipulation Weak email verification Invitation bypass Test carefully using authorized test accounts only.\n2. Login Testing The login flow should resist brute force, credential stuffing, enumeration, and session abuse.\nChecklist:\nIs rate limiting enforced per account and per IP? Are failed login attempts monitored? Are error messages generic? Does the login response reveal whether an email exists? Are weak passwords accepted? Does the application support MFA for sensitive accounts? Are login attempts logged? Is there protection against automated login attempts? Weak error message example:\nThis email does not exist. Better generic message:\nInvalid email or password. Generic messages reduce account enumeration risk.\nImage: Type: Test case, Mô tả: \u0026ldquo;A safe lab screenshot showing two login attempts with different invalid credentials and identical generic error messages.\u0026rdquo;. caption: \u0026ldquo;Authentication error messages should avoid revealing whether an account exists.\u0026rdquo;\n3. Password Policy Testing A password policy should balance security and usability.\nChecklist:\nAre very weak passwords rejected? Is a minimum length enforced? Are common breached passwords blocked? Is password reuse restricted where appropriate? Are passwords stored using a strong password hashing algorithm? Are password fields protected from accidental logging? Avoid relying only on complexity rules. A long passphrase is often stronger and more usable than a short complex password.\n4. Password Reset Testing Password reset is one of the most critical flows because it can directly lead to account takeover.\nChecklist:\nAre reset tokens random and unpredictable? Do reset tokens expire quickly? Are reset tokens single-use? Are old tokens invalidated after a new token is issued? Is the token bound to the correct account? Does changing the password invalidate active sessions? Can the reset link be poisoned through the Host header? Does the reset flow leak whether an email exists? Is rate limiting applied to reset requests? Common vulnerabilities:\nPredictable reset token Token reuse Missing token expiration Password reset poisoning Account enumeration Session not invalidated after reset Safe test idea:\nUse two lab accounts. Request reset tokens for both accounts and verify that a token for Account A cannot reset Account B.\n5. Email Change Testing Email change is sometimes overlooked but can be high impact.\nChecklist:\nIs the current password required before email change? Is confirmation required on the old email? Is confirmation required on the new email? Can users change email to an already registered email? Are active sessions invalidated after email change? Can the email change token be reused? Is the flow protected against CSRF? If email is used for login or password reset, insecure email change can become account takeover.\n6. MFA Testing Multi-Factor Authentication improves security, but weak implementation can still be bypassed.\nChecklist:\nIs MFA enforced for sensitive accounts? Can users access sensitive pages before completing MFA? Is MFA required after password reset? Are backup codes protected and single-use? Is there rate limiting on OTP attempts? Can the MFA step be skipped by directly browsing to authenticated endpoints? Are remember-device tokens secure? Is MFA disabled without strong verification? Common issue:\nUser logs in with password -\u0026gt; MFA page appears -\u0026gt; user directly accesses /dashboard -\u0026gt; access granted This indicates that MFA is enforced only in the frontend or workflow, not in the backend authorization state.\n7. Session Management Testing After authentication succeeds, the session becomes the main proof of identity.\nChecklist:\nAre session tokens random and unpredictable? Are cookies set with HttpOnly, Secure, and appropriate SameSite? Is the session rotated after login? Is the session invalidated after logout? Are sessions invalidated after password reset? Is there an idle timeout? Is there an absolute session lifetime? Can multiple sessions be managed by the user? Are tokens exposed in URLs? Cookies should not expose sensitive values such as roles, permissions, or raw user IDs unless properly protected and validated.\n8. Logout Testing Logout should invalidate the server-side session or token state where applicable.\nChecklist:\nDoes logout invalidate the session server-side? Can the old session cookie still be reused? Are refresh tokens revoked? Is logout available from all devices? Does logout clear client-side storage? A logout button that only clears the browser cookie without invalidating the backend session may not be sufficient.\n9. Account Lockout and Rate Limiting Rate limiting must be designed carefully. Too weak, and brute force becomes possible. Too aggressive, and attackers can lock out legitimate users.\nChecklist:\nIs rate limiting applied to login? Is rate limiting applied to password reset? Is rate limiting applied to OTP/MFA? Is rate limiting applied per account and per source? Are lockouts temporary and safe? Are suspicious attempts logged? Do not perform aggressive brute force testing unless explicitly authorized in the rules of engagement.\n10. OAuth and SSO Testing If the application uses OAuth or SSO, review:\nredirect_uri validation state parameter protection Token leakage in URLs Account linking logic Email verification from identity provider Scope handling Logout behavior Session binding OAuth issues often happen when the application trusts identity data without verifying the full flow correctly.\n11. Logging and Alerting Authentication events should be logged and monitored.\nImportant events:\nFailed login attempts Successful login Password reset request Password changed Email changed MFA enabled/disabled New device login Suspicious login pattern Account lockout Logs should support investigation without exposing sensitive secrets.\nQuick Checklist Use this condensed checklist during testing:\nRegistration prevents abuse and role manipulation Login has generic errors and rate limiting Password policy blocks weak passwords Password reset tokens are random, expiring, and single-use Email change requires strong verification MFA cannot be skipped or brute-forced Sessions are secure, rotated, and invalidated properly Logout invalidates active sessions or tokens OAuth/SSO flows validate redirect URI, state, and identity claims Sensitive authentication events are logged and monitored Image: Type: Context, Mô tả: \u0026ldquo;A checklist-style graphic summarizing registration, login, password reset, MFA, session, logout, and logging.\u0026rdquo;. caption: \u0026ldquo;Authentication testing should cover the entire account lifecycle.\u0026rdquo;\nReporting Authentication Issues A good report should explain:\nWhich flow is affected What security control failed How the issue can be reproduced safely What account takeover or abuse scenario is possible What remediation is recommended Example root cause statement:\nThe password reset token remains valid after it is used once. An attacker who obtains a previously used token may reuse it to reset the victim\u0026#39;s password again. Reset tokens should be single-use and invalidated immediately after successful password reset. Conclusion Authentication testing is not limited to the login form. A complete review should cover the full account lifecycle: registration, login, password reset, email change, MFA, session management, logout, recovery, logging, and alerting.\nThe safest mindset is to ask:\nCan an attacker become another user, keep access longer than intended, or bypass identity verification through an edge case?\nIf the answer is yes, the authentication design needs improvement.\nReferences OWASP Web Security Testing Guide - Authentication Testing: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/README OWASP Application Security Verification Standard: https://owasp.org/www-project-application-security-verification-standard/ OWASP Cheat Sheet Series - Authentication: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html PortSwigger Web Security Academy - Authentication: https://portswigger.net/web-security/authentication Need Help? KevinSec helps teams review authentication flows, password reset logic, MFA enforcement, and session management. If you need an authentication-focused security review, contact KevinSec through the Contact page.\n","permalink":"https://kevinsec.io/blog/authentication-testing-checklist-for-web-applications/","summary":"Use this checklist to review login, registration, password reset, session management, MFA, and account recovery flows.","title":"Authentication Testing Checklist for Web Applications"},{"content":"Broken Access Control: Why It Is Still Critical Broken Access Control is one of the most important vulnerability categories in web application security. It happens when an application fails to enforce what an authenticated user is allowed to access or modify.\nThis issue is dangerous because it often appears in normal business features, not only in obviously technical endpoints. A user profile page, invoice download, project dashboard, order history, admin panel, or API endpoint can all become vulnerable if authorization checks are incomplete.\nThe core idea is simple:\nAuthentication proves who the user is. Authorization decides what the user is allowed to do.\nWhen applications confuse these two concepts, broken access control appears.\nImage: Type: Context, Mô tả: \u0026ldquo;A simple diagram showing User A trying to access User B\u0026rsquo;s invoice through an object ID, with a missing authorization check highlighted.\u0026rdquo;. caption: \u0026ldquo;Broken access control occurs when the server fails to verify whether the current user is allowed to access the requested object or action.\u0026rdquo;\nAuthentication Is Not Enough Many applications correctly require login but fail to enforce proper authorization after login.\nExample:\nGET /api/invoices/7788 Authorization: Bearer token-for-user-A If invoice 7788 belongs to User B, the server must reject the request. It is not enough to check that the token is valid. The server must verify that User A is allowed to access invoice 7788.\nThis is why broken access control can be subtle. The application may appear secure because unauthenticated users are blocked. But authenticated users may still access other users\u0026rsquo; data.\nCommon Broken Access Control Patterns 1. IDOR Insecure Direct Object Reference occurs when a user can change an object identifier and access another user\u0026rsquo;s object.\nExamples:\n/api/users/1001 /api/orders/7788 /download?file_id=9001 If changing the ID returns another user\u0026rsquo;s data, the root cause is missing object-level authorization.\n2. Horizontal Privilege Escalation Horizontal privilege escalation happens when one normal user accesses another normal user\u0026rsquo;s data or actions.\nExample:\nUser A views User B\u0026rsquo;s profile details User A downloads User B\u0026rsquo;s invoice User A updates User B\u0026rsquo;s address Both users may have the same role, but they should not access each other\u0026rsquo;s resources.\n3. Vertical Privilege Escalation Vertical privilege escalation happens when a lower-privileged user performs higher-privileged actions.\nExample:\nPOST /admin/users/disable If a normal user can call this endpoint successfully, the system has a serious authorization flaw.\n4. Missing Function-Level Authorization Sometimes the UI hides admin features, but the backend does not enforce authorization.\nThis is a common mistake:\nThe admin button is hidden from normal users The normal user manually sends the admin request The backend accepts the action Security must be enforced server-side. Hiding UI elements is not access control.\n5. Forced Browsing Forced browsing happens when users access URLs or endpoints directly without going through the intended workflow.\nExamples:\n/admin /export/all-users.csv /internal/reports/monthly If these paths are accessible without proper authorization, sensitive data or functionality may be exposed.\nWhy Broken Access Control Is Still Common Authorization Logic Is Business-Specific Unlike input validation or password hashing, authorization rules are often unique to each business.\nFor example:\nWho can approve a payment? Who can view a project? Can a manager view all team members? Can support staff reset customer data? Can users access invoices after leaving an organization? These rules are difficult for automated scanners to understand.\nModern Applications Have Many Roles and Objects Applications now include:\nUsers Organizations Teams Projects Workspaces API keys Invoices Reports Admin functions Shared resources Each object may require different authorization logic.\nAPIs Expose More Direct Access APIs often expose object IDs directly:\nGET /api/projects/123 PATCH /api/users/456 DELETE /api/files/789 This creates a large attack surface for object-level access control issues.\nFrontend Authorization Is Misunderstood Modern single-page applications often contain frontend route guards or role checks. These checks improve user experience but do not replace backend enforcement.\nA user can still call the backend directly using tools such as Burp Suite, curl, or browser dev tools.\nImpact of Broken Access Control The impact depends on the object and action involved.\nPossible impact includes:\nPersonal data exposure Account takeover Unauthorized financial transactions Privilege escalation Data modification or deletion Admin function abuse Compliance violations Loss of customer trust Broken access control often has high business impact because it directly affects confidentiality, integrity, and sometimes availability.\nHow to Test Safely Use authorized test accounts with different roles.\nExample setup:\nAccount Role Purpose User A Normal user Owns object A User B Normal user Owns object B Manager Elevated user Limited admin functions Admin Administrator Full access Testing flow:\nLog in as User A. Capture a request for User A\u0026rsquo;s object. Log in as User B and identify User B\u0026rsquo;s object ID. As User A, attempt to access User B\u0026rsquo;s object in the authorized lab or assessment scope. Verify whether the server rejects the request. Image: Type: Test case, Mô tả: \u0026ldquo;A Burp Suite Repeater screenshot in a lab showing two requests with different object IDs and different authorization contexts.\u0026rdquo;. caption: \u0026ldquo;Access control testing requires at least two accounts to verify object ownership and role boundaries.\u0026rdquo;\nTesting Checklist Review these areas:\nCan User A access User B\u0026rsquo;s object? Can a normal user call admin endpoints directly? Can object IDs be changed in paths, query strings, headers, or JSON bodies? Are authorization checks enforced server-side? Are roles checked for every sensitive action? Does the API verify object ownership? Can users access deleted, archived, or inactive resources? Can users modify fields they should not control? Are export/download endpoints protected? Are batch operations properly authorized per object? Common Remediation Strategies Enforce Server-Side Authorization Every sensitive request must be authorized on the server.\nDo not rely on:\nHidden buttons Frontend routes Disabled form fields Client-side role checks Obscure URLs Deny by Default The safe default is to deny access unless explicitly allowed.\nCheck Object Ownership For object-based access, verify that the current user has permission to access the specific object.\nExample logic:\ncurrent_user must be owner of invoice OR have organization-level permission to view invoices Centralize Authorization Logic Authorization logic should not be randomly duplicated across controllers. Use centralized policies, middleware, guards, or permission services where appropriate.\nLog Sensitive Authorization Failures Failed access attempts to sensitive resources should be logged and reviewed.\nHow to Explain It to Developers A clear explanation helps remediation.\nWeak report:\nI changed the ID and saw another user\u0026rsquo;s data.\nBetter report:\nThe endpoint validates authentication but does not enforce object-level authorization. An authenticated user can change the invoice ID in the request path and retrieve invoices belonging to other users. The server should verify that the requested invoice belongs to the current user or that the user has an authorized role to access it.\nThis explains root cause and remediation clearly.\nConclusion Broken Access Control remains critical because it is deeply connected to business logic. It is not just a technical mistake. It is a failure to enforce who can access what, under which conditions, and for which actions.\nFor pentesters, this category should be tested carefully with multiple accounts and clear authorization boundaries. For developers, authorization must be treated as a server-side security requirement, not a UI feature.\nReferences OWASP Top 10:2025 - Broken Access Control: https://owasp.org/Top10/2025/en/ OWASP Web Security Testing Guide - Authorization Testing: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/README OWASP API Security Top 10 2023 - BOLA: https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/ Need Help? KevinSec provides practical web and API security testing with a strong focus on access control, authorization logic, and business impact. If you need to validate whether your application enforces access control correctly, contact KevinSec through the Contact page.\n","permalink":"https://kevinsec.io/blog/broken-access-control-why-it-is-still-critical/","summary":"Broken access control allows authenticated users to access data or actions they should not be allowed to access.","title":"Broken Access Control: Why It Is Still Critical"},{"content":"How to Read an HTTP Request Like a Pentester Every web vulnerability starts with a simple question: what data is being sent, where does it go, and who is allowed to control it?\nFor a pentester, an HTTP request is not just a network message. It is a map of the application\u0026rsquo;s trust boundaries. It shows user input, authentication state, authorization context, business actions, and sometimes hidden assumptions made by developers.\nIf you can read an HTTP request well, you can often predict where vulnerabilities may exist before sending a single payload.\nImage: Type: Context, Mô tả: \u0026ldquo;A clean diagram showing an HTTP request split into method, path, query string, headers, cookies, and body.\u0026rdquo;. caption: \u0026ldquo;An HTTP request is a map of user-controlled data and application trust boundaries.\u0026rdquo;\nA Basic HTTP Request A typical request may look like this:\nPOST /api/profile/update?user_id=1024 HTTP/1.1 Host: app.example.com User-Agent: Mozilla/5.0 Content-Type: application/json Authorization: Bearer eyJhbGciOi... Cookie: session=abc123; theme=dark Origin: https://app.example.com Referer: https://app.example.com/profile { \u0026#34;displayName\u0026#34;: \u0026#34;Kevin\u0026#34;, \u0026#34;email\u0026#34;: \u0026#34;kevin@example.com\u0026#34;, \u0026#34;role\u0026#34;: \u0026#34;user\u0026#34; } A normal user may see this as a profile update request. A pentester sees multiple questions:\nCan the user_id be changed? Is the Authorization token properly validated? Is the session cookie secure? Does the server trust the role value from the client? Are Origin and Referer used for any security decision? Is the JSON body validated server-side? That is the difference between reading traffic and testing security.\n1. Start With the HTTP Method The method tells you the intended action.\nCommon methods include:\nMethod Common meaning Pentest angle GET Read data Data exposure, IDOR, caching issues POST Create or submit data Injection, CSRF, business logic abuse PUT Replace data Unauthorized update, mass assignment PATCH Partially update data Object/property-level authorization issues DELETE Delete data Missing authorization, destructive action abuse A sensitive action using GET is a signal worth reviewing. For example, deleting an object through a URL like /delete?id=123 may increase the risk of CSRF, accidental execution, and caching problems.\nA PUT, PATCH, or DELETE request should immediately trigger an authorization question: who is allowed to perform this action on this object?\n2. Read the Path Like a Business Function The path usually reveals the feature being accessed.\nExamples:\n/api/users/1024 /api/orders/7788/invoice /admin/users/disable /profile/avatar/upload /password/reset/confirm A pentester should classify the path by business function:\nAccount management Authentication Authorization Payment File upload Admin action Reporting/export Internal API Integration endpoint The more sensitive the function, the more carefully it should be tested.\nFor example, /api/orders/7788/invoice suggests object-level access control. The key question is not only whether the user is logged in, but whether the user owns order 7788 or has a legitimate role to access it.\n3. Inspect Query Parameters Query parameters are often user-controlled and easy to manipulate.\n?user_id=1024 ?redirect=https://example.com ?file=report.pdf ?next=/dashboard ?debug=true ?sort=created_at Each parameter creates a hypothesis:\nParameter pattern Possible issue id, user_id, order_id IDOR, BOLA, broken access control redirect, next, returnUrl Open redirect, OAuth abuse file, path, template Path traversal, file disclosure debug, test, admin Security misconfiguration sort, filter, search Injection, excessive data exposure A good pentester does not blindly fuzz every parameter. They first ask: what does this parameter control?\n4. Review Authentication Headers and Cookies Authentication state is usually represented through headers or cookies.\nCommon examples:\nAuthorization: Bearer \u0026lt;token\u0026gt; Cookie: session=\u0026lt;value\u0026gt; X-API-Key: \u0026lt;key\u0026gt; Questions to ask:\nIs the token required for this endpoint? Does the endpoint behave differently without authentication? Does the token expire properly? Can the same token be reused after logout? Are cookies protected with HttpOnly, Secure, and SameSite? Is the API key scoped to specific actions? A request that returns sensitive data without a valid token is an obvious problem. A request that requires a token but fails to verify object ownership is a more subtle and common problem.\n5. Treat the Request Body as Untrusted Data The body is where applications often receive structured input:\n{ \u0026#34;name\u0026#34;: \u0026#34;Kevin\u0026#34;, \u0026#34;email\u0026#34;: \u0026#34;kevin@example.com\u0026#34;, \u0026#34;role\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;isAdmin\u0026#34;: false } The important question is whether the server trusts fields that should never be client-controlled.\nDangerous fields include:\nrole isAdmin isVerified balance price discount ownerId permission status If the client can submit privileged fields, test for mass assignment and broken object property-level authorization. The server should enforce sensitive values based on server-side logic, not client-provided input.\nImage: Type: Test case, Mô tả: \u0026ldquo;A Burp Suite Repeater screenshot in a local lab showing a JSON request where an unexpected field such as isAdmin is added for testing.\u0026rdquo;. caption: \u0026ldquo;Unexpected fields in JSON bodies can reveal mass assignment or authorization weaknesses.\u0026rdquo;\n6. Check Headers That Influence Security Decisions Some headers can change application behavior:\nHost: app.example.com Origin: https://app.example.com Referer: https://app.example.com/profile X-Forwarded-Host: evil.example X-Forwarded-For: 127.0.0.1 Content-Type: application/json Potential risks:\nHost and X-Forwarded-Host: password reset poisoning, routing issues, cache poisoning Origin: CORS misconfiguration Referer: weak CSRF validation if used incorrectly X-Forwarded-For: IP-based access control bypass in poorly designed systems Content-Type: parser confusion or validation bypass A header should not be trusted just because it looks technical. Many headers are still user-controllable.\n7. Identify Object Identifiers Object identifiers are one of the strongest signals in a request.\nExamples:\n/user/1024 /order/7788 invoice_id=9001 projectId=abc-123 fileUuid=550e8400-e29b-41d4-a716-446655440000 Ask three questions:\nWhat object is being referenced? Who owns this object? Does the server verify that the current user is allowed to access it? Changing an ID in a lab environment is a simple way to test for IDOR or BOLA. However, in real assessments, stay within the authorized scope and use test accounts provided for the engagement.\n8. Understand the Difference Between Authentication and Authorization Authentication answers: who are you?\nAuthorization answers: what are you allowed to do?\nA request can pass authentication but still fail authorization.\nExample:\nGET /api/users/2048/profile Authorization: Bearer token-for-user-1024 If the token belongs to user 1024, but the endpoint returns data for user 2048, the issue is likely broken access control.\nThis distinction is critical. Many real-world vulnerabilities are not caused by missing login. They are caused by missing authorization checks after login.\n9. Build a Testing Hypothesis When reading any request, write a short hypothesis:\nEndpoint: POST /api/profile/update?user_id=1024 Action: Update user profile Sensitive object: user profile User-controlled input: user_id, JSON body fields Primary risks: IDOR, mass assignment, stored XSS, weak authorization Safe test: Use two authorized lab accounts and verify cross-account access is blocked This keeps testing structured and prevents random payload spraying.\nPractical Checklist When you see an HTTP request, review:\nMethod: is this read, create, update, or delete? Path: what business function is being accessed? Parameters: which values are user-controlled? Object IDs: can they reference another user\u0026rsquo;s resource? Headers: do any headers affect security decisions? Cookies/tokens: how is the user authenticated? Body: are sensitive fields client-controlled? Response: does it expose data or confirm unauthorized action? Role context: would another user, lower-privileged user, or unauthenticated user get the same result? How to Practice Safely Use legal labs such as PortSwigger Web Security Academy, DVWA, or OWASP Juice Shop. Capture requests in Burp Suite, send them to Repeater, and practice reading the request before testing anything.\nA good training rule is: do not send a payload until you can explain what the request is doing.\nConclusion Reading HTTP requests is a core pentesting skill. The goal is not to memorize payloads. The goal is to recognize patterns: object IDs, trust boundaries, sensitive actions, authentication state, and user-controlled data.\nOnce you can read a request like this, vulnerabilities become easier to reason about and reports become easier to write.\nReferences OWASP Web Security Testing Guide: https://owasp.org/www-project-web-security-testing-guide/ OWASP Top 10:2025: https://owasp.org/Top10/2025/en/ PortSwigger Web Security Academy: https://portswigger.net/web-security Need Help? KevinSec helps teams review web applications, APIs, and authentication flows from an attacker-informed perspective. If you need a practical web security review or pentest readiness assessment, contact KevinSec through the Contact page.\n","permalink":"https://kevinsec.io/blog/how-to-read-an-http-request-like-a-pentester/","summary":"Learn how pentesters inspect HTTP methods, paths, parameters, headers, cookies, and request bodies to identify potential security risks.","title":"How to Read an HTTP Request Like a Pentester"},{"content":"IDOR Explained with a Simple Lab Scenario IDOR stands for Insecure Direct Object Reference. It is a common access control vulnerability where an application exposes a direct reference to an internal object and fails to verify whether the current user is allowed to access that object.\nIn simple terms:\nIf changing an ID in a request lets you access another user\u0026rsquo;s data, you may be looking at IDOR.\nIDOR is part of the broader Broken Access Control category. It is especially common in APIs because object IDs often appear directly in paths, query parameters, or request bodies.\nImage: Type: Context, Mô tả: \u0026ldquo;A simple diagram showing User A requesting /api/invoices/1001 and then changing the ID to /api/invoices/1002, which belongs to User B.\u0026rdquo;. caption: \u0026ldquo;IDOR happens when the server trusts the object ID but does not verify whether the current user is authorized to access it.\u0026rdquo;\nThe Core Concept Consider this request:\nGET /api/invoices/1001 HTTP/1.1 Host: lab.example Authorization: Bearer token-for-user-a If invoice 1001 belongs to User A, the request is legitimate.\nNow consider this modified request:\nGET /api/invoices/1002 HTTP/1.1 Host: lab.example Authorization: Bearer token-for-user-a If invoice 1002 belongs to User B, the server should reject the request.\nIf the server returns User B\u0026rsquo;s invoice to User A, the application is vulnerable to IDOR.\nRoot Cause The root cause is missing object-level authorization.\nThe application checks:\nIs the user logged in? But fails to check:\nIs this user allowed to access this specific object? Authentication is not enough. The server must enforce authorization for every object and action.\nA Simple Lab Scenario Use only legal labs or authorized test environments such as PortSwigger Web Security Academy, DVWA, or OWASP Juice Shop.\nImagine a training application with two accounts:\nAccount Role Object owned Alice Normal user Invoice 1001 Bob Normal user Invoice 1002 Alice logs in and views her invoice:\nGET /account/invoices/1001 HTTP/1.1 Host: vulnerable-lab.local Cookie: session=alice-session The application returns Alice\u0026rsquo;s invoice.\nThe tester then changes the object ID:\nGET /account/invoices/1002 HTTP/1.1 Host: vulnerable-lab.local Cookie: session=alice-session Expected secure behavior:\nHTTP/1.1 403 Forbidden Vulnerable behavior:\nHTTP/1.1 200 OK Invoice owner: Bob Amount: $500 This is IDOR because Alice can access Bob\u0026rsquo;s object by modifying a direct object reference.\nImage: Type: Test case, Mô tả: \u0026ldquo;A PortSwigger-style lab screenshot or Burp Suite Repeater screenshot showing an object ID changed from one authorized object to another test user\u0026rsquo;s object.\u0026rdquo;. caption: \u0026ldquo;A safe IDOR test compares access between two authorized lab accounts.\u0026rdquo;\nWhere IDOR Appears IDOR can appear in many places.\nURL Paths /users/1024 /orders/7788 /files/9001 Query Parameters /download?file_id=9001 /profile?user_id=1024 /report?id=7788 JSON Bodies { \u0026#34;userId\u0026#34;: 1024, \u0026#34;invoiceId\u0026#34;: 7788 } HTTP Headers X-User-ID: 1024 X-Account-ID: 7788 GraphQL Variables { \u0026#34;id\u0026#34;: \u0026#34;VXNlcjoxMDI0\u0026#34; } The object reference does not have to be a simple number. It can be a UUID, hash, base64 value, slug, file name, or encoded global ID.\nNumeric IDs vs UUIDs Some teams believe that replacing numeric IDs with UUIDs fixes IDOR.\nUUIDs can reduce guessability, but they do not replace authorization.\nIf a user obtains another user\u0026rsquo;s UUID through search results, logs, shared links, browser history, API responses, or leaked data, the same issue may still exist.\nThe real fix is server-side authorization.\nIDOR Impact Impact depends on the object and action.\nRead-only IDOR may expose:\nPersonal data Invoices Documents Support tickets Private messages API keys Internal reports Write-based IDOR may allow:\nUpdating another user\u0026rsquo;s profile Deleting another user\u0026rsquo;s files Changing shipping addresses Modifying project settings Canceling orders Approving actions Write-based IDOR is often more severe because it affects integrity, not only confidentiality.\nHow to Test IDOR Safely A proper test requires at least two accounts.\nStep 1: Create or obtain two test accounts Use accounts that are explicitly authorized for testing.\nUser A: alice@example.test User B: bob@example.test Step 2: Capture User A\u0026rsquo;s request Use Burp Suite Proxy or browser dev tools.\nExample:\nGET /api/documents/501 Step 3: Identify User B\u0026rsquo;s equivalent object Log in as User B and find a similar request:\nGET /api/documents/702 Step 4: Replay User A\u0026rsquo;s request with User B\u0026rsquo;s object ID While authenticated as User A, change 501 to 702.\nStep 5: Evaluate the response Secure outcomes:\n403 Forbidden 404 Not Found Empty result Generic error without data exposure Vulnerable outcome:\nUser B\u0026rsquo;s object is returned User B\u0026rsquo;s object is modified The action succeeds without authorization What to Include in a Report A good IDOR report should include:\nAffected endpoint Roles/accounts used Original authorized request Modified unauthorized request Evidence of unauthorized access Business impact Clear remediation Example root cause statement:\nThe endpoint validates that the requester is authenticated but does not verify that the requested invoice belongs to the authenticated user. As a result, an authenticated user can modify the invoice ID and retrieve invoices belonging to other users. Remediation Enforce Object-Level Authorization For every object access, the server should verify ownership or permission.\nExample:\ninvoice.owner_id == current_user.id or:\ncurrent_user has organization permission: invoice:read Avoid Trusting Client-Supplied Ownership Do not trust values like:\n{ \u0026#34;ownerId\u0026#34;: 123, \u0026#34;userId\u0026#34;: 456 } The server should derive ownership from the authenticated session and database records.\nApply Authorization to Every Action Authorization must be enforced for:\nRead Create Update Delete Export Share Approve Batch operations Use Centralized Authorization Policies Centralized policies reduce inconsistent authorization logic across endpoints.\nCommon Mistakes Avoid these assumptions:\n\u0026ldquo;The endpoint requires login, so it is safe.\u0026rdquo; \u0026ldquo;The ID is a UUID, so users cannot guess it.\u0026rdquo; \u0026ldquo;The frontend hides the button, so users cannot access it.\u0026rdquo; \u0026ldquo;Only mobile apps use this API, so users cannot modify requests.\u0026rdquo; \u0026ldquo;The object ID is encoded, so it is protected.\u0026rdquo; These assumptions fail because clients are under user control.\nConclusion IDOR is simple to understand but still very common. The vulnerability appears when an application exposes object references and fails to enforce object-level authorization.\nFor pentesters, the key is to test with multiple authorized accounts and compare access boundaries. For developers, the key is to enforce authorization on the server for every object and action.\nReferences OWASP API Security Top 10 2023 - Broken Object Level Authorization: https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/ OWASP Web Security Testing Guide - Authorization Testing: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/README PortSwigger Web Security Academy - Access Control: https://portswigger.net/web-security/access-control Need Help? KevinSec helps teams test object-level authorization across web applications and APIs. If you want to validate whether your application is vulnerable to IDOR or BOLA, contact KevinSec through the Contact page.\n","permalink":"https://kevinsec.io/blog/idor-explained-with-a-simple-lab-scenario/","summary":"Learn how Insecure Direct Object Reference works, why it happens, and how to test it safely in labs such as PortSwigger, DVWA, or OWASP Juice Shop.","title":"IDOR Explained with a Simple Lab Scenario"},{"content":"OWASP Top 10 2025 Explained for Beginners The OWASP Top 10 is one of the most recognized awareness documents in web application security. It is not a complete pentest checklist and it is not a replacement for secure design, threat modeling, or the OWASP Web Security Testing Guide.\nIts purpose is simpler: help developers, security engineers, managers, and learners understand the most critical categories of web application security risk.\nThe 2025 version reflects how modern applications are changing. Web systems are now more connected, more dependent on third-party software, more API-driven, and more exposed to complex failure modes.\nImage: Type: Context, Mô tả: \u0026ldquo;A clean infographic listing the OWASP Top 10 2025 categories from A01 to A10.\u0026rdquo;. caption: \u0026ldquo;The OWASP Top 10 2025 is an awareness document for understanding major web application security risks.\u0026rdquo;\nThe OWASP Top 10 2025 Categories The OWASP Top 10 2025 categories are:\nID Category A01:2025 Broken Access Control A02:2025 Security Misconfiguration A03:2025 Software Supply Chain Failures A04:2025 Cryptographic Failures A05:2025 Injection A06:2025 Insecure Design A07:2025 Authentication Failures A08:2025 Software or Data Integrity Failures A09:2025 Security Logging \u0026amp; Alerting Failures A10:2025 Mishandling of Exceptional Conditions For beginners, the best way to use this list is to treat each category as a mental model. Each category helps you ask better questions when reviewing a web application.\nA01: Broken Access Control Broken Access Control happens when users can access data or actions they should not be allowed to access.\nExamples:\nViewing another user\u0026rsquo;s invoice Updating another user\u0026rsquo;s profile Accessing admin endpoints as a normal user Bypassing role checks Modifying object IDs to access unauthorized records This category is critical because authentication alone is not enough. A user can be logged in and still perform unauthorized actions if authorization checks are missing.\nBeginner question:\nCan this user access or modify something that belongs to another user or a higher-privileged role?\nA02: Security Misconfiguration Security Misconfiguration occurs when systems are deployed with unsafe settings.\nExamples:\nDebug mode enabled in production Default credentials Verbose error messages Exposed admin panels Missing security headers Open cloud storage buckets Directory listing enabled Misconfiguration is common because modern applications depend on many layers: web servers, frameworks, containers, cloud services, CI/CD pipelines, and third-party platforms.\nBeginner question:\nIs the application exposing something that should not be exposed?\nA03: Software Supply Chain Failures Modern applications rely heavily on dependencies, packages, build systems, containers, third-party libraries, and CI/CD processes.\nSoftware Supply Chain Failures happen when trust in these components is abused or when weak dependency management introduces risk.\nExamples:\nVulnerable open-source package Compromised dependency Unpinned package versions Exposed CI/CD secrets Insecure build artifacts Dependency confusion This category reminds us that application security is not only about custom code. The software supply chain is part of the attack surface.\nBeginner question:\nWhat external code, package, or build process does this application trust?\nA04: Cryptographic Failures Cryptographic Failures happen when sensitive data is not properly protected.\nExamples:\nStoring passwords without strong hashing Using weak encryption algorithms Transmitting sensitive data over HTTP Poor key management Hardcoded secrets Missing encryption for sensitive data at rest For beginners, avoid thinking of cryptography as only \u0026ldquo;complex math.\u0026rdquo; In web security, the practical question is whether sensitive data is protected correctly.\nBeginner question:\nIs sensitive data protected during storage, transmission, and processing?\nA05: Injection Injection happens when untrusted data is interpreted as part of a command, query, expression, or document structure.\nExamples:\nSQL injection NoSQL injection Command injection LDAP injection Server-side template injection XPath injection The root cause is usually unsafe handling of untrusted data. The application mixes user input with trusted instructions.\nBeginner question:\nCan user-controlled input change the meaning of a backend query or command?\nImage: Type: Test case, Mô tả: \u0026ldquo;A local lab screenshot showing a search parameter being sent to a SQL-backed feature in a safe training environment.\u0026rdquo;. caption: \u0026ldquo;Injection risks appear when user input reaches an interpreter such as SQL, shell, template engine, or expression parser.\u0026rdquo;\nA06: Insecure Design Insecure Design is different from implementation bugs. It means the application is designed in a way that does not properly address security requirements.\nExamples:\nNo abuse protection in a coupon system No approval workflow for sensitive actions Password reset flow that does not consider account takeover scenarios Business logic that trusts the client too much Missing rate limits by design A secure implementation of an insecure design can still be vulnerable.\nBeginner question:\nDoes the feature design prevent realistic abuse cases?\nA07: Authentication Failures Authentication Failures happen when identity verification is weak or incorrectly implemented.\nExamples:\nWeak password policy No rate limiting on login Predictable reset tokens Session not invalidated after logout MFA bypass Credential stuffing exposure Authentication is a high-value target because it protects access to accounts.\nBeginner question:\nCan someone prove they are another user, reuse a session, or bypass identity checks?\nA08: Software or Data Integrity Failures Software or Data Integrity Failures happen when the application trusts software updates, data, plugins, serialized objects, or pipelines without verifying integrity.\nExamples:\nInsecure deserialization Unsigned updates CI/CD pipeline tampering Plugin integrity issues Trusting unverified data from external systems This category is closely related to supply chain risk, but focuses on integrity: can the system verify that software and data have not been tampered with?\nBeginner question:\nDoes the application verify the integrity of software, data, and updates before trusting them?\nA09: Security Logging \u0026amp; Alerting Failures Security Logging \u0026amp; Alerting Failures happen when attacks occur but the organization cannot detect, investigate, or respond properly.\nExamples:\nNo logging for failed logins No alert for privilege changes No audit trail for admin actions Sensitive events not monitored Logs missing user ID, source IP, or object ID Security is not only prevention. Detection and response matter.\nBeginner question:\nIf this attack happened, would the team know?\nA10: Mishandling of Exceptional Conditions Mishandling of Exceptional Conditions refers to unsafe behavior when the system enters unusual, unexpected, overloaded, or error states.\nExamples:\nFailing open when a security check errors Revealing sensitive stack traces Continuing transactions after partial failure Inconsistent state after timeout Business logic bypass during edge cases This is especially important in complex distributed systems where failure is normal.\nBeginner question:\nWhat happens when something fails, times out, or receives unexpected input?\nHow Beginners Should Use the OWASP Top 10 Do not treat the OWASP Top 10 as a payload list. Treat it as a thinking framework.\nFor each feature, ask:\nWho can access this? What data is trusted? What happens if input is unexpected? What third-party components are involved? What sensitive data is processed? What happens during failure? Would the team detect abuse? Then use the OWASP Web Security Testing Guide for deeper testing methodology.\nSuggested Learning Order For beginners, I recommend this order:\nHTTP basics Authentication vs authorization Broken Access Control and IDOR XSS and Injection File upload and path traversal Security misconfiguration API security basics Logging, monitoring, and reporting Secure design and business logic Supply chain and integrity risks This order builds practical understanding before moving into advanced topics.\nConclusion The OWASP Top 10 2025 is a strong starting point for learning web application security. It helps beginners understand the major risk categories and gives teams a shared language for discussing application risk.\nHowever, real security work requires more than naming categories. You must understand root cause, business impact, safe testing methods, and practical remediation.\nReferences OWASP Top 10:2025: https://owasp.org/Top10/2025/en/ OWASP Top Ten Project: https://owasp.org/www-project-top-ten/ OWASP Web Security Testing Guide: https://owasp.org/www-project-web-security-testing-guide/ OWASP API Security Top 10 2023: https://owasp.org/www-project-api-security/ Need Help? KevinSec helps teams translate security standards like the OWASP Top 10 into practical web application testing, risk assessment, and remediation guidance. If you need a focused web security review, contact KevinSec through the Contact page.\n","permalink":"https://kevinsec.io/blog/owasp-top-10-2025-explained-for-beginners/","summary":"Understand the OWASP Top 10 2025 categories, what they mean, and how beginners should use them in web security learning.","title":"OWASP Top 10 2025 Explained for Beginners"},{"content":"Untrusted Data: The Root of Most Web Vulnerabilities A large number of web vulnerabilities can be explained with one sentence:\nThe application trusted data it should not have trusted.\nThat data may come from a form field, URL parameter, JSON body, cookie, HTTP header, uploaded file, third-party integration, webhook, or even another internal service.\nFor a pentester or developer, understanding untrusted data is more important than memorizing payloads. Once you know where untrusted data enters the system, you can reason about injection, XSS, IDOR, SSRF, mass assignment, file upload bugs, and many other vulnerability classes.\nImage: Type: Context, Mô tả: \u0026ldquo;A simple trust-boundary diagram showing user/browser/external API sending data into a web application, then to business logic, database, filesystem, and internal services.\u0026rdquo;. caption: \u0026ldquo;Untrusted data becomes dangerous when it crosses a trust boundary without validation, authorization, or encoding.\u0026rdquo;\nWhat Is Untrusted Data? Untrusted data is any data that the application cannot fully control.\nExamples include:\nURL paths and query parameters Form fields JSON or XML request bodies Cookies HTTP headers Uploaded files JWT claims if not properly validated Webhook payloads Data from third-party APIs Data stored previously by another user The key idea is simple: if a user, browser, client, partner, or external system can influence it, treat it as untrusted.\nUntrusted does not mean malicious by default. It means the application must not assume the data is safe, authorized, correctly formatted, or semantically valid.\nWhy This Matters Many applications are designed around happy paths.\nA developer expects:\n{ \u0026#34;displayName\u0026#34;: \u0026#34;Kevin\u0026#34;, \u0026#34;email\u0026#34;: \u0026#34;kevin@example.com\u0026#34; } But an attacker-controlled client may send:\n{ \u0026#34;displayName\u0026#34;: \u0026#34;Kevin\u0026#34;, \u0026#34;email\u0026#34;: \u0026#34;kevin@example.com\u0026#34;, \u0026#34;role\u0026#34;: \u0026#34;admin\u0026#34;, \u0026#34;isVerified\u0026#34;: true } If the server blindly maps all fields into a user object, the problem is not the JSON format. The problem is misplaced trust.\nCommon Sources of Untrusted Data 1. Query Parameters /search?q=laptop /download?file=report.pdf /profile?user_id=1024 Query parameters often control what data is retrieved, displayed, filtered, or downloaded.\nPotential issues:\nSQL injection Reflected XSS Path traversal IDOR Open redirect Excessive data exposure 2. Request Body { \u0026#34;productId\u0026#34;: 1001, \u0026#34;quantity\u0026#34;: 2, \u0026#34;price\u0026#34;: 1 } If the server trusts client-side values like price, role, discount, or ownerId, the application may become vulnerable to business logic flaws or mass assignment.\n3. Cookies Cookies are stored on the client side. Even if they look internal, they can often be modified by the user.\nDangerous assumptions include:\nTrusting isAdmin=true from a cookie Storing unsigned role information Using predictable session identifiers Missing HttpOnly, Secure, or SameSite flags 4. HTTP Headers Headers such as Host, Origin, Referer, X-Forwarded-For, and Content-Type can influence application behavior.\nPotential issues:\nHost header injection CORS misconfiguration Weak CSRF validation IP-based access control bypass Request parsing inconsistencies 5. Uploaded Files Uploaded files are high-risk because they combine content, metadata, file names, and storage paths.\nPotential issues:\nUnrestricted file upload Malware upload Path traversal through file names Stored XSS through SVG/HTML Remote code execution in poorly configured environments Image: Type: Test case, Mô tả: \u0026ldquo;A local lab screenshot showing a file upload request in Burp Suite with filename, Content-Type, and file content highlighted.\u0026rdquo;. caption: \u0026ldquo;File upload requests contain multiple user-controlled surfaces: filename, MIME type, metadata, and content.\u0026rdquo;\nHow Untrusted Data Becomes a Vulnerability Untrusted data becomes dangerous when it reaches a sensitive sink.\nA sink is where data is used in a security-sensitive way.\nExamples:\nSource Sink Possible vulnerability URL parameter SQL query SQL injection Form field HTML response XSS File parameter Filesystem path Path traversal URL parameter Internal HTTP request SSRF JSON body User model Mass assignment Object ID Database lookup IDOR/BOLA Header Password reset link Host header injection The basic mental model is:\nSource -\u0026gt; Processing -\u0026gt; Sink A pentester should track how untrusted data moves from source to sink.\nExample: From Parameter to SQL Injection Consider:\nGET /products?category=books If the backend builds a query like this:\nSELECT * FROM products WHERE category = \u0026#39;\u0026lt;user input\u0026gt;\u0026#39; The user-controlled value reaches a SQL query. If the application does not use parameterized queries, SQL injection may be possible.\nThe root cause is not merely a special character. The root cause is that untrusted data is treated as part of a trusted query structure.\nExample: From Object ID to IDOR Consider:\nGET /api/invoices/7788 Authorization: Bearer token-for-user-A If the user changes 7788 to another invoice ID and receives someone else\u0026rsquo;s invoice, the application has an authorization problem.\nThe root cause is not the use of numeric IDs. The root cause is that the server trusted the requested object ID without verifying ownership or permission.\nExample: From Stored Input to Stored XSS A user submits a display name:\nKevin The application stores it and later renders it in another user\u0026rsquo;s browser.\nIf output encoding is missing, malicious HTML or JavaScript may execute.\nThis is important: stored data can still be untrusted. Data does not become safe just because it was saved to a database.\nDefensive Controls Validate Input Validation checks whether data is expected.\nGood validation is:\nServer-side Allowlist-based Type-aware Length-limited Business-rule aware Example: if quantity must be an integer from 1 to 10, enforce that rule on the server.\nEnforce Authorization Input validation does not answer whether the user is allowed to access an object.\nFor object IDs, always verify:\nDoes the object exist? Who owns it? What role does the current user have? Is this action allowed for this user on this object? Use Context-Aware Output Encoding For XSS prevention, output must be encoded based on where it appears:\nHTML body HTML attribute JavaScript context URL context CSS context Encoding must match the output context.\nUse Parameterized Queries For SQL injection prevention, do not build queries by string concatenation. Use prepared statements or safe ORM patterns.\nAvoid Client-Side Trust Never trust client-side values for security decisions.\nExamples of values that should be server-controlled:\nRole Permission Price Discount Account balance Ownership Approval status Pentester Checklist When reviewing a feature, ask:\nWhat data can the user control? Is the data validated server-side? Does the data reach a sensitive sink? Is authorization checked after authentication? Is output encoded based on context? Are dangerous fields accepted from the client? Can stored data affect other users later? Does the application trust headers, cookies, or hidden fields? How to Practice Safely Use lab platforms such as PortSwigger Web Security Academy, DVWA, or OWASP Juice Shop. Pick one feature and trace every piece of user-controlled data from request to response.\nDo not start with payloads. Start with data flow.\nConclusion Untrusted data is one of the most important concepts in web security. Vulnerabilities happen when applications allow untrusted data to influence queries, HTML output, filesystem paths, authorization decisions, internal requests, or business logic.\nFor pentesters, this concept improves pattern recognition. For developers, it improves secure design. For security teams, it provides a common language for explaining root cause.\nReferences OWASP Web Security Testing Guide: https://owasp.org/www-project-web-security-testing-guide/ OWASP Top 10:2025: https://owasp.org/Top10/2025/en/ OWASP Cheat Sheet Series: https://cheatsheetseries.owasp.org/ Need Help? KevinSec helps teams identify how untrusted data flows through web applications and APIs. If you want a practical security review focused on real attack paths, contact KevinSec through the Contact page.\n","permalink":"https://kevinsec.io/blog/untrusted-data-root-of-most-web-vulnerabilities/","summary":"Most web vulnerabilities happen when applications trust data controlled by users, browsers, integrations, or external systems.","title":"Untrusted Data: The Root of Most Web Vulnerabilities"},{"content":"Abstract This is a sample Research note for KevinSec.\nThe purpose of this template is to standardize how technical findings, vulnerability analysis, and experiments are documented.\nContext Every research note should begin with enough context for the reader to understand the target, technology, or security problem.\nFor vulnerability analysis, this section should explain:\nThe affected component. The trust boundary. The relevant user-controlled or untrusted data. The expected security behavior. Root Cause Explain why the issue exists.\nFor example:\nMissing input validation. Broken access control. Unsafe deserialization. Insecure default configuration. Incorrect trust assumption. Methodology Figure 1. Test Image Document the approach used to analyze or reproduce the issue.\nA good methodology section should include:\nTest environment. Tools used. Steps performed. Assumptions. Limitations. Findings Describe the observed behavior.\nInclude evidence where appropriate, such as:\nGET /example HTTP/1.1 Host: vulnerable.example User-Agent: KevinSec-Research Impact Explain the security impact. Impact should be specific. Avoid vague claims. Good examples: Unauthorized data access. Account takeover. Privilege escalation. Server-side request forgery. Remote code execution. Sensitive information disclosure. Mitigation Document practical remediation steps. Examples: Validate and normalize user input. Enforce authorization checks server-side. Apply allowlist-based validation. Disable unsafe features. Patch the affected component. Add monitoring and detection rules. Conclusion Summarize the finding and the practical lesson learned.\nA good research note should help both offensive and defensive readers understand the issue.\n","permalink":"https://kevinsec.io/research/sample-research-note/","summary":"A structured template for vulnerability analysis and technical research notes.","title":"Research Note Template for Vulnerability Analysis"},{"content":"Introduction This is a sample Blog post for KevinSec.\nThe purpose of this post is to define a clean writing pattern for practical security notes.\nStructure A good Blog post should be short, useful, and easy to scan.\nRecommended structure:\nContext Key idea Practical lesson Checklist Final note Practical Lesson For KevinSec, Blog posts should focus on clarity and practical value.\nThe goal is not only to publish content, but to build trust through consistent technical thinking.\nChecklist Before publishing a Blog post:\nCheck title and summary. Check tags and categories. Check cover image. Check mobile layout. Check grammar. Check whether the post gives the reader one useful takeaway. Final Note This sample post can be used as a reference when creating future Blog content.\n","permalink":"https://kevinsec.io/blog/sample-blog-post/","summary":"A short note on how I structure practical security writing for KevinSec.","title":"How I Structure Practical Security Notes"},{"content":"Welcome This is the first article created using Decap CMS.\nMission Offensive Security Research Pentest Education Roadmap Web Security Red Team CVE Research ","permalink":"https://kevinsec.io/blog/welcome-to-kevinsec/","summary":"\u003ch1 id=\"welcome\"\u003eWelcome\u003c/h1\u003e\n\u003cp\u003eThis is the first article created using Decap CMS.\u003c/p\u003e\n\u003ch2 id=\"mission\"\u003eMission\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eOffensive Security\u003c/li\u003e\n\u003cli\u003eResearch\u003c/li\u003e\n\u003cli\u003ePentest\u003c/li\u003e\n\u003cli\u003eEducation\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"roadmap\"\u003eRoadmap\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eWeb Security\u003c/li\u003e\n\u003cli\u003eRed Team\u003c/li\u003e\n\u003cli\u003eCVE Research\u003c/li\u003e\n\u003c/ol\u003e","title":"Welcome to KevinSec"}]