क्वेरी रनर रीड-ओन्ली करण्यासाठी SQL पार्स करू नका

SQL स्ट्रिंग्समध्ये कीवर्ड्स शोधून तुमचा डेटाबेस सुरक्षित करण्याचा प्रयत्न करणे थांबवा.

जर तुम्ही SQL चालवण्यासाठी एखादे टूल बनवत असाल, तर तुम्हाला 'रीड-ओन्ली' (read-only) मोड हवा असेल. चुकून झालेल्या UPDATE मुळे तुमचा डेटा डिलीट होऊ नये असे तुम्हाला वाटेल. DELETE किंवा DROP सारखे शब्द ब्लॉक करणे हा तुमचा पहिला विचार असू शकतो.

असे करू नका.

स्ट्रिंग चेक (String checks) बायपास करणे सोपे आहे. वापरकर्ता DELETE लपवण्यासाठी WITH क्लॉज वापरू शकतो. ते कमांड्स लपवण्यासाठी कमेंट्स वापरू शकतात. ते टेबलमध्ये डेटा लिहिणारे फंक्शन कॉल करू शकतात. शेवटी तुम्ही 'whack-a-mole' सारख्या कधीही न जिंकता येणाऱ्या खेळात अडकता.

सुरक्षा हाताळण्यासाठी डेटाबेसवर विश्वास ठेवा.

Postgres मध्ये यासाठी इन-बिल्ट (built-in) फीचर आहे. तुम्ही ट्रान्झॅक्शनला (transaction) 'रीड-ओन्ली' म्हणून घोषित करू शकता. त्यानंतर सर्व्हर कोणत्याही 'राईट' (write) कमांडला नकार देतो. यामध्ये CTEs, फंक्शन्स आणि DDL यांचा समावेश होतो.

पायथनमध्ये (Python) याची योग्य अंमलबजावणी कशी करायची ते खाली दिले आहे:

ही पद्धत SQL टेक्स्टची तपासणी करत नाही. क्वेरी जशी लिहिली आहे तशीच सर्व्हरकडे जाते. तुम्ही इंजिनला (engine) नियम लागू करण्यास सांगत आहात.

सुरक्षिततेसाठी दोन गोष्टी आवश्यक आहेत:

  1. 'राईट'पासून संरक्षण: रीड-ओन्ली ट्रान्झॅक्शन्स वापरा.
  2. रिसोर्सच्या गैरवापरापासून संरक्षण: टाइमआउट्स (timeouts) आणि रो लिमिट्स (row limits) वापरा.

एखादी रीड-ओन्ली क्वेरी मोठ्या 'join' मुळे तुमची सिस्टम क्रॅश करू शकते. रीड-ओन्ली ट्रान्झॅक्शन 'राईट्स' थांबवते, पण ते रिसोर्सेसचा अतिवापर थांबवत नाही. ॲड-हॉक (ad-hoc) SQL सुरक्षित करण्यासाठी तुम्हाला या दोन्ही गोष्टींची गरज आहे.

SQL पार्स करणे थांबवा. डेटाबेसला त्याचे काम करू द्या.

स्त्रोत: https://dev.to/hitoshi1964/dont-parse-sql-to-make-a-query-runner-read-only-b62