mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/rsql-injection.md'] to el
This commit is contained in:
Translator
parent
6667173ff8
commit
04b8377ee4
@ -10,14 +10,14 @@
|
||||
Το RSQL είναι μια γλώσσα ερωτημάτων σχεδιασμένη για παραμετροποιημένο φιλτράρισμα εισροών σε RESTful APIs. Βασισμένο στο FIQL (Feed Item Query Language), που αρχικά καθορίστηκε από τον Mark Nottingham για την αναζήτηση Atom feeds, το RSQL ξεχωρίζει για την απλότητά του και την ικανότητά του να εκφράζει σύνθετα ερωτήματα με συμπαγή και συμβατό τρόπο με URI μέσω HTTP. Αυτό το καθιστά εξαιρετική επιλογή ως γενική γλώσσα ερωτημάτων για την αναζήτηση σημείων REST.
|
||||
|
||||
## Επισκόπηση
|
||||
Η RSQL Injection είναι μια ευπάθεια σε διαδικτυακές εφαρμογές που χρησιμοποιούν το RSQL ως γλώσσα ερωτημάτων σε RESTful APIs. Παρόμοια με το [SQL Injection](https://owasp.org/www-community/attacks/SQL_Injection) και το [LDAP Injection](https://owasp.org/www-community/attacks/LDAP_Injection), αυτή η ευπάθεια συμβαίνει όταν τα φίλτρα RSQL δεν είναι σωστά καθαρισμένα, επιτρέποντας σε έναν επιτιθέμενο να εισάγει κακόβουλα ερωτήματα για να αποκτήσει, να τροποποιήσει ή να διαγράψει δεδομένα χωρίς εξουσιοδότηση.
|
||||
Η RSQL Injection είναι μια ευπάθεια σε διαδικτυακές εφαρμογές που χρησιμοποιούν το RSQL ως γλώσσα ερωτημάτων σε RESTful APIs. Παρόμοια με την [SQL Injection](https://owasp.org/www-community/attacks/SQL_Injection) και την [LDAP Injection](https://owasp.org/www-community/attacks/LDAP_Injection), αυτή η ευπάθεια συμβαίνει όταν τα φίλτρα RSQL δεν είναι σωστά καθαρισμένα, επιτρέποντας σε έναν επιτιθέμενο να εισάγει κακόβουλα ερωτήματα για να αποκτήσει, να τροποποιήσει ή να διαγράψει δεδομένα χωρίς εξουσιοδότηση.
|
||||
|
||||
## Πώς λειτουργεί;
|
||||
Το RSQL σας επιτρέπει να δημιουργείτε προηγμένα ερωτήματα σε RESTful APIs, για παράδειγμα:
|
||||
```bash
|
||||
/products?filter=price>100;category==electronics
|
||||
```
|
||||
Αυτό μεταφράζεται σε μια δομημένη ερώτηση που φιλτράρει προϊόντα με τιμή μεγαλύτερη από 100 και κατηγορία “ηλεκτρονικά”.
|
||||
Αυτό μεταφράζεται σε μια δομημένη ερώτηση που φιλτράρει προϊόντα με τιμή μεγαλύτερη από 100 και κατηγορία "ηλεκτρονικά".
|
||||
|
||||
Εάν η εφαρμογή δεν επικυρώνει σωστά την είσοδο του χρήστη, ένας επιτιθέμενος θα μπορούσε να χειριστεί το φίλτρο για να εκτελέσει απροσδόκητες ερωτήσεις, όπως:
|
||||
```bash
|
||||
@ -30,7 +30,7 @@
|
||||
- **Τροποποίηση ή διαγραφή δεδομένων:** Εισαγωγή φίλτρων που αλλοιώνουν τις εγγραφές της βάσης δεδομένων.
|
||||
- **Αύξηση προνομίων:** Χειρισμός αναγνωριστικών που παρέχουν ρόλους μέσω φίλτρων για να παραπλανήσουν την εφαρμογή αποκτώντας πρόσβαση με προνόμια άλλων χρηστών.
|
||||
- **Αποφυγή ελέγχων πρόσβασης:** Χειρισμός φίλτρων για πρόσβαση σε περιορισμένα δεδομένα.
|
||||
- **Ψευδώνυμο ή IDOR:** Τροποποίηση αναγνωριστικών μεταξύ χρηστών μέσω φίλτρων που επιτρέπουν πρόσβαση σε πληροφορίες και πόρους άλλων χρηστών χωρίς να είναι σωστά πιστοποιημένοι ως τέτοιοι.
|
||||
- **Ψευδής ταυτοποίηση ή IDOR:** Τροποποίηση αναγνωριστικών μεταξύ χρηστών μέσω φίλτρων που επιτρέπουν πρόσβαση σε πληροφορίες και πόρους άλλων χρηστών χωρίς να είναι σωστά πιστοποιημένοι ως τέτοιοι.
|
||||
|
||||
## Υποστηριζόμενοι RSQL τελεστές
|
||||
| Τελεστής | Περιγραφή | Παράδειγμα |
|
||||
@ -88,7 +88,7 @@
|
||||
| `search` | Εκτελεί μια πιο ευέλικτη αναζήτηση | `/api/v2/posts?search=technology` |
|
||||
|
||||
## Διαρροή πληροφοριών και αρίθμηση χρηστών
|
||||
Το παρακάτω αίτημα δείχνει ένα endpoint εγγραφής που απαιτεί την παράμετρο email για να ελέγξει αν υπάρχει οποιοσδήποτε χρήστης εγγεγραμμένος με αυτό το email και να επιστρέψει αληθές ή ψευδές ανάλογα με το αν υπάρχει ή όχι στη βάση δεδομένων:
|
||||
Το παρακάτω αίτημα δείχνει ένα endpoint εγγραφής που απαιτεί την παράμετρο email για να ελέγξει αν υπάρχει κάποιος χρήστης εγγεγραμμένος με αυτό το email και να επιστρέψει αληθές ή ψευδές ανάλογα με το αν υπάρχει ή όχι στη βάση δεδομένων:
|
||||
### Αίτημα
|
||||
```
|
||||
GET /api/registrations HTTP/1.1
|
||||
@ -125,7 +125,7 @@ Content-Length: 85
|
||||
}]
|
||||
}
|
||||
```
|
||||
Αν και αναμένεται ένα `/api/registrations?email=<emailAccount>`, είναι δυνατόν να χρησιμοποιηθούν φίλτρα RSQL για να προσπαθήσουν να καταγράψουν και/ή να εξάγουν πληροφορίες χρηστών μέσω της χρήσης ειδικών τελεστών:
|
||||
Αν και αναμένεται ένα `/api/registrations?email=<emailAccount>`, είναι δυνατόν να χρησιμοποιηθούν φίλτρα RSQL για να προσπαθήσετε να καταγράψετε και/ή να εξαγάγετε πληροφορίες χρηστών μέσω της χρήσης ειδικών τελεστών:
|
||||
### Request
|
||||
```
|
||||
GET /api/registrations?filter[userAccounts]=email=='test@test.com' HTTP/1.1
|
||||
@ -162,7 +162,7 @@ Access-Control-Allow-Origin: *
|
||||
}
|
||||
}
|
||||
```
|
||||
Σε περίπτωση που ταιριάζει ένας έγκυρος λογαριασμός email, η εφαρμογή θα επιστρέψει τις πληροφορίες του χρήστη αντί για ένα κλασικό *“true”*, *"1"* ή οτιδήποτε άλλο στην απάντηση προς τον διακομιστή:
|
||||
Σε περίπτωση που ταιριάζει ένας έγκυρος λογαριασμός email, η εφαρμογή θα επιστρέψει τις πληροφορίες του χρήστη αντί για ένα κλασικό *“true”*, *"1"* ή οτιδήποτε άλλο στην απάντηση προς τον διακομιστή:
|
||||
### Request
|
||||
```
|
||||
GET /api/registrations?filter[userAccounts]=email=='manuel**********@domain.local' HTTP/1.1
|
||||
@ -208,7 +208,7 @@ Access-Control-Allow-Origin: *
|
||||
}
|
||||
}
|
||||
```
|
||||
## Εξαπάτηση εξουσιοδότησης
|
||||
## Εξαίρεση εξουσιοδότησης
|
||||
Σε αυτό το σενάριο, ξεκινάμε από έναν χρήστη με βασικό ρόλο και στον οποίο δεν έχουμε προνομιακές άδειες (π.χ. διαχειριστής) για να αποκτήσουμε πρόσβαση στη λίστα όλων των χρηστών που είναι εγγεγραμμένοι στη βάση δεδομένων:
|
||||
### Αίτημα
|
||||
```
|
||||
@ -238,7 +238,7 @@ Vary: Access-Control-Request-Method
|
||||
Vary: Access-Control-Request-Headers
|
||||
Access-Control-Allow-Origin: *
|
||||
```
|
||||
Και πάλι χρησιμοποιούμε τα φίλτρα και τους ειδικούς τελεστές που θα μας επιτρέψουν μια εναλλακτική μέθοδο για να αποκτήσουμε τις πληροφορίες των χρηστών και να παρακάμψουμε τον έλεγχο πρόσβασης. Για παράδειγμα, φιλτράρουμε τους *χρήστες* που περιέχουν το γράμμα “*a*” στο *ID* χρήστη τους:
|
||||
Και πάλι χρησιμοποιούμε τα φίλτρα και τους ειδικούς τελεστές που θα μας επιτρέψουν μια εναλλακτική μέθοδο για να αποκτήσουμε τις πληροφορίες των χρηστών και να παρακάμψουμε τον έλεγχο πρόσβασης. Για παράδειγμα, φιλτράρουμε τους *χρήστες* που περιέχουν το γράμμα “*a*” στο *ID* τους:
|
||||
### Request
|
||||
```
|
||||
GET /api/users?filter[users]=id=in=(*a*) HTTP/1.1
|
||||
@ -365,7 +365,23 @@ Sec-Fetch-Dest: empty
|
||||
Sec-Fetch-Mode: cors
|
||||
Sec-Fetch-Site: same-site
|
||||
```
|
||||
### Απόκριση
|
||||
### Αντίκτυπος
|
||||
|
||||
Η RSQL Injection είναι μια τεχνική που επιτρέπει στους επιτιθέμενους να εκτελούν αυθαίρετες εντολές SQL σε μια βάση δεδομένων μέσω μιας ευάλωτης εφαρμογής. Αυτή η τεχνική εκμεταλλεύεται την αδυναμία της εφαρμογής να επικυρώσει σωστά τις εισόδους του χρήστη.
|
||||
|
||||
#### Πώς λειτουργεί
|
||||
|
||||
Η RSQL Injection εκμεταλλεύεται την ελλιπή επικύρωση των παραμέτρων που αποστέλλονται στην εφαρμογή. Όταν οι παράμετροι αυτοί χρησιμοποιούνται για τη δημιουργία ερωτημάτων SQL, οι επιτιθέμενοι μπορούν να εισάγουν κακόβουλο κώδικα SQL, ο οποίος μπορεί να οδηγήσει σε διαρροή δεδομένων ή ακόμα και σε πλήρη έλεγχο της βάσης δεδομένων.
|
||||
|
||||
#### Προστασία
|
||||
|
||||
Για να προστατευθείτε από την RSQL Injection, είναι σημαντικό να:
|
||||
|
||||
1. Χρησιμοποιείτε παραμετροποιημένα ερωτήματα.
|
||||
2. Επικυρώνετε και φιλτράρετε όλες τις εισόδους του χρήστη.
|
||||
3. Εφαρμόζετε περιορισμούς στα δικαιώματα πρόσβασης στη βάση δεδομένων.
|
||||
|
||||
Αυτές οι πρακτικές μπορούν να μειώσουν σημαντικά τον κίνδυνο επιθέσεων RSQL Injection.
|
||||
```
|
||||
HTTP/1.1 200
|
||||
Date: Sat, 22 Mar 2025 19:13:45 GMT
|
||||
@ -395,7 +411,7 @@ Access-Control-Allow-Origin: *
|
||||
}]
|
||||
}
|
||||
```
|
||||
Μετά την γνώση ενός αναγνωριστικού ενός χρήστη διαχειριστή, θα ήταν δυνατό να εκμεταλλευτούμε μια κλιμάκωση προνομίων αντικαθιστώντας ή προσθέτοντας το αντίστοιχο φίλτρο με το αναγνωριστικό του διαχειριστή και αποκτώντας τα ίδια προνόμια:
|
||||
Μετά την αναγνώριση ενός αναγνωριστικού ενός χρήστη διαχειριστή, θα ήταν δυνατό να εκμεταλλευτεί κανείς μια κλιμάκωση προνομίων αντικαθιστώντας ή προσθέτοντας το αντίστοιχο φίλτρο με το αναγνωριστικό του διαχειριστή και αποκτώντας τα ίδια προνόμια:
|
||||
### Request
|
||||
```
|
||||
GET /api/functionalities/allPermissionsFunctionalities?filter[companyUsers]=user.id=='94****************************' HTTP/1.1
|
||||
@ -459,7 +475,7 @@ Access-Control-Allow-Origin: *
|
||||
.......
|
||||
```
|
||||
## Υποκατάσταση ή Αναφορές Άμεσων Αντικειμένων χωρίς Ασφάλεια (IDOR)
|
||||
Εκτός από τη χρήση της παραμέτρου `filter`, είναι δυνατή η χρήση άλλων παραμέτρων όπως η `include`, η οποία επιτρέπει την συμπερίληψη ορισμένων παραμέτρων στο αποτέλεσμα (π.χ. γλώσσα, χώρα, κωδικός πρόσβασης...).
|
||||
Εκτός από τη χρήση της παραμέτρου `filter`, είναι δυνατή η χρήση άλλων παραμέτρων όπως η `include`, η οποία επιτρέπει την συμπερίληψη στο αποτέλεσμα ορισμένων παραμέτρων (π.χ. γλώσσα, χώρα, κωδικός πρόσβασης...).
|
||||
|
||||
Στο παρακάτω παράδειγμα, εμφανίζεται η πληροφορία του προφίλ του χρήστη μας:
|
||||
### Request
|
||||
@ -479,7 +495,7 @@ Sec-Fetch-Dest: empty
|
||||
Sec-Fetch-Mode: cors
|
||||
Sec-Fetch-Site: same-site
|
||||
```
|
||||
### Απάντηση
|
||||
### Απόκριση
|
||||
```
|
||||
HTTP/1.1 200
|
||||
Date: Sat, 22 Mar 2025 19:47:27 GMT
|
||||
@ -533,7 +549,7 @@ Sec-Fetch-Dest: empty
|
||||
Sec-Fetch-Mode: cors
|
||||
Sec-Fetch-Site: same-site
|
||||
```
|
||||
### Απάντηση
|
||||
### Απόκριση
|
||||
```
|
||||
HTTP/1.1 200
|
||||
Date: Sat, 22 Mar 2025 19:50:07 GMT
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user