# Access control testing: μεθοδολογία για IDOR/BOLA με το Burp Suite

**URL:** <https://forum.iguru.gr/t/access-control-testing-idor-bola-burp-suite/175>\
**Category:** /pentesting\
**Created:** [November 10, 2026, 6:39am UTC](https://forum.iguru.gr/t/access-control-testing-idor-bola-burp-suite/175 "2026-11-10T06:39:55Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://forum.iguru.gr/uploads/default/original/1X/96d4854ffa9560674a510c0710f31f15e4cbc5cd.png) [@system](https://forum.iguru.gr/u/system)\
**Post date:** [November 10, 2026, 6:39am UTC](https://forum.iguru.gr/t/access-control-testing-idor-bola-burp-suite/175/1 "2026-11-10T06:39:55Z")

</div>

Τα σφάλματα πρόσβασης είναι εδώ και χρόνια στην κορυφή της λίστας: πρώτη θέση στο OWASP Top 10 (A01, Broken Access Control) και πρώτη θέση στο OWASP API Security Top 10 (API1, Broken Object Level Authorization). Δεν τα πιάνουν σχεδόν ποτέ οι αυτόματοι scanners, γιατί ο scanner δεν ξέρει ποια δεδομένα ανήκουν σε ποιον. Γι’ αυτό είναι ιδανικό πεδίο για μεθοδικό, χειροκίνητο testing. Ακολουθεί η μεθοδολογία που χρησιμοποιώ σε web και API engagements.

## Πριν από οτιδήποτε: εξουσιοδότηση και κανόνες

• **Γραπτή εξουσιοδότηση** από τον ιδιοκτήτη του συστήματος, με σαφές scope: domains, APIs, περιβάλλοντα (ιδανικά staging).

• **Rules of engagement:** ώρες, όρια ρυθμού αιτημάτων, τι απαγορεύεται (π.χ. διαγραφές σε production), ποιος ειδοποιείται αν βρεθεί κάτι κρίσιμο.

• **Δοκιμαστικοί λογαριασμοί** που σας δίνει ο πελάτης. Δεν δοκιμάζουμε ποτέ πάνω σε δεδομένα πραγματικών χρηστών.

• **Ελάχιστη πρόσβαση:** μόλις αποδείξετε ότι ένα object είναι προσβάσιμο, σταματάτε. Δεν «κατεβάζουμε» δεδομένα για να δείξουμε το μέγεθος του προβλήματος.

## Η προετοιμασία

Χρειάζεστε τουλάχιστον τρεις ταυτότητες: **χρήστη Α** , **χρήστη Β** στον ίδιο ρόλο, και έναν **διαχειριστή** (ή έναν χρήστη υψηλότερου ρόλου). Με τον Α και τον Β ελέγχετε την οριζόντια κλιμάκωση (πρόσβαση στα δεδομένα άλλου χρήστη), με τον Α απέναντι στον διαχειριστή την κάθετη (πρόσβαση σε λειτουργίες υψηλότερου ρόλου).

Στο Burp, περιηγηθείτε σε όλη την εφαρμογή με κάθε ταυτότητα, ώστε το Proxy history να καλύπτει κάθε λειτουργία. Στη συνέχεια καταγράψτε κάθε σημείο όπου ο client αναφέρεται σε ένα object:

• αριθμητικά IDs και UUIDs στο path (/api/v1/invoices/10452)

• πεδία μέσα σε JSON bodies (“accountId”: 10452)

• query parameters, headers, ακόμη και cookies

• σε GraphQL: τα arguments των queries και των mutations, και τα nested objects

## Οι τεχνικές

• **Ανταλλαγή session:** επαναλάβετε ένα αίτημα του Α που αφορά δικό του object, με το session του Β. Αν η απάντηση περιέχει τα δεδομένα του Α, έχετε BOLA.

• **Αλλαγή μεθόδου:** ένα endpoint μπορεί να ελέγχει σωστά το GET αλλά όχι το PUT, το PATCH ή το DELETE στο ίδιο path.

• **Mass assignment:** προσθέστε πεδία που δεν στέλνει ο client, όπως “role”: “admin” ή “ownerId”, και δείτε αν ο server τα αποδέχεται.

• **Κάθετη κλιμάκωση:** καλέστε endpoints του διαχειριστή με το session απλού χρήστη. Η απόκρυψη ενός κουμπιού στο UI δεν είναι έλεγχος πρόσβασης.

• **Εναλλακτικοί δρόμοι:** εξαγωγές (CSV, PDF), λειτουργίες αναζήτησης, παλαιότερες εκδόσεις του API (/v1/ δίπλα στο /v2/), mobile endpoints.

Ένας μύθος που αξίζει να καταρριφθεί: τα UUIDs δεν προστατεύουν. Δυσκολεύουν το μάντεμα, αλλά συχνά διαρρέουν από άλλα σημεία της εφαρμογής: λίστες, ειδοποιήσεις, logs, URLs που μοιράζονται.

## Αυτοματοποίηση με extensions

Με δεκάδες endpoints, η χειροκίνητη ανταλλαγή session γίνεται κουραστική. Δύο extensions του Burp κάνουν τη δουλειά:

• **Autorize:** περιηγείστε ως χρήστης με υψηλότερα δικαιώματα, και η extension επαναλαμβάνει κάθε αίτημα αυτόματα με το session ενός χρήστη με χαμηλότερα δικαιώματα (και χωρίς session), συγκρίνοντας τις απαντήσεις.

• **AuthMatrix:** ορίζετε ρόλους και αιτήματα σε πίνακα, και ελέγχετε συστηματικά ποιος ρόλος έχει πρόσβαση πού.

Προσοχή στα ψευδώς θετικά: μια απάντηση 200 με ίδιο μέγεθος δεν σημαίνει απαραίτητα διαρροή. Μπορεί να είναι μια γενική σελίδα σφάλματος. Ελέγχετε πάντα το περιεχόμενο.

## Το report

• **Βήματα αναπαραγωγής** με τα ακριβή αιτήματα, με τα tokens λογοκριμένα.

• **Απόδειξη με την ελάχιστη δυνατή έκθεση δεδομένων:** ένα πεδίο αρκεί.

• **Αξιολόγηση με CVSS 4.0,** και κυρίως η επιχειρηματική επίπτωση: ποια δεδομένα, πόσων χρηστών.

• **Συγκεκριμένη αποκατάσταση:** έλεγχος εξουσιοδότησης στον server για κάθε object, με βάση την ταυτότητα της session και όχι τιμές που στέλνει ο client· «deny by default»· κεντρική πολιτική πρόσβασης αντί για ελέγχους διάσπαρτους σε κάθε endpoint· και regression tests που δοκιμάζουν ρητά πρόσβαση με λάθος χρήστη.

## Για συζήτηση

1. Ποια εργαλεία ή extensions χρησιμοποιείτε για access control testing, και πώς χειρίζεστε τα ψευδώς θετικά;

2. Πώς προσεγγίζετε το GraphQL, όπου ένα μόνο endpoint κρύβει δεκάδες λειτουργίες;

3. Ποιο ήταν το πιο «απρόσμενο» σημείο όπου βρήκατε BOLA: εξαγωγές, ειδοποιήσεις, παλιά versions του API;