AI-உதவி பெற்ற AuthZ ஆய்வு: Ory Kratos-இல் அனுமதி எல்லைகளைப் (Permission Boundaries) படித்தல்

பிழைகளைக் (bugs) கண்டறிவதில் AI பலவீனமானது, ஆனால் சந்தேகங்களை உருவாக்குவதில் சிறந்தது.

பாதுகாப்பைப் பொறுத்தவரை, ஒரு AI செய்யக்கூடிய மிக எளிதான காரியம் தவறான அறிக்கைகளின் வெள்ளத்தை உருவாக்குவதாகும். இதனால்தான் bug bounty திட்டங்கள் தங்களது விதிகளை நிறுத்தி வைக்கின்றன அல்லது இறுக்கமாக்குகின்றன.

நான் AI-ஐ வேறு விதமாகப் பயன்படுத்துகிறேன். எனது AuthZ Smell Catalog-ஐ அடிப்படையாகக் கொண்டு, AI அதிகப்படியான கருதுகோள்களை (hypotheses) உருவாக்க அனுமதிக்கிறேன். பிறகு, கடினமான வேலையை நான் செய்கிறேன். அந்த கருதுகோள்களைத் தகர்ப்பதே எனது வேலை.

ஒரு வெற்றிகரமான ஆய்வு என்பது பிழைகளின் பட்டியல் அல்ல. அது சோதனையில் தோல்வியடைந்த யோசனைகளின் ஒரு 'kill table' ஆகும்.

நான் Ory Kratos மூலக் குறியீட்டை (source code) ஆய்வு செய்தேன். Kratos அடையாளங்கள் (identity) மற்றும் பயனர் நிர்வாகத்தைக் கையாள்கிறது. இது பல அடையாளங்களையும் பொது API-களையும் பயன்படுத்துவதால், அதிக ஆபத்துள்ள ஒரு பகுதியாகும்.

நான் ஐந்து கருதுகோள்களைச் சோதித்தேன்:

  • H1: Admin API-இல் குறியீட்டிற்குள் (code) அங்கீகாரம் (authorization) இல்லை.
  • H2: Cross-identity அல்லது cross-tenant தரவு கசிவுகள்.
  • H3: Recovery flows-இல் டோக்கன்களை மீண்டும் பயன்படுத்துதல்.
  • H4: Settings flows-இல் அடையாளக் குழப்பம் (Identity confusion).
  • H5: Request payloads மூலம் tenant ஒதுக்கீடு செய்தல்.

முடிவுகள்:

  • H1: தகர்க்கப்பட்டது (KILLED). அங்கீகாரம் என்பது நெட்வொர்க் எல்லையில் (network boundary) உள்ளது, குறியீடு கையாளுதலில் (code handler) இல்லை. இது திட்டமிட்ட வடிவமைப்பே ஆகும்.
  • H2: தகர்க்கப்பட்டது (KILLED). ஒரு மைய தரவு அணுகல் அடுக்கு (central data-access layer), அனைத்து வினவல்களையும் (queries) tenant ID மூலம் வடிகட்டுகிறது. பயனர்களால் இதைத் தவிர்க்க முடியாது.
  • H3: தகர்க்கப்பட்டது (KILLED). டோக்கன்கள் ஒருமுறை மட்டுமே பயன்படுத்தக்கூடியவை மற்றும் குறிப்பிட்ட கால வரம்பு கொண்டவை.
  • H4: தகர்க்கப்பட்டது (KILLED). Flows ஆகியவை பயனரின் உள்ளீட்டுடன் (user input) அல்லாமல், அமர்வுடன் (session) பிணைக்கப்பட்டுள்ளன.
  • H5: தகர்க்கப்பட்டது (KILLED). Tenant ID-கள் சிஸ்டம் சூழலில் (system context) இருந்து வருகின்றன, கோரிக்கை உடலிலிருந்து (request body) அல்ல.

ஐந்து கருதுகோள்கள் உள்ளே சென்றன. பூஜ்ஜிய கண்டுபிடிப்புகள் வெளியே வந்தன. இதுவே ஒரு வெற்றிகரமான ஆய்வு.

உங்கள் பாதுகாப்புப் பணிக்கான இரண்டு பாடங்கள்:

  1. Deployment-layer பாதுகாப்பு என்பது பாதுகாப்பு இல்லாதது போலத் தோன்றும். ஒரு பாதுகாவலர் நெட்வொர்க் மட்டத்தில் இருந்தால், குறியீடு பாதுகாப்பற்றது போலத் தெரியும். கட்டமைப்பை (architecture) சரிபார்க்கும் வரை அதைத் தெரிவிக்க வேண்டாம்.

  2. நெரிப்புப் புள்ளியைக் (chokepoint) கண்டறியுங்கள். ஒரு அமைப்பு தரவு மட்டத்தில் (data layer) எல்லைகளைக் கட்டாயமாக்கினால், தனிப்பட்ட கையாளுதல்களுக்கு (individual handlers) சோதனைகள் தேவையில்லை. "இந்தக் கையாளுதல் அனுமதிகளைச் சரிபார்க்கிறதா?" என்று கேட்பதற்குப் பதிலாக, "நெரிப்புப் புள்ளியின்றி யாராவது தரவை அடைய முடியுமா?" என்று கேளுங்கள்.

தகுதியற்றவற்றை நிராகரிக்க AI-ஐப் பயன்படுத்துங்கள். தகுதியுள்ளவற்றைச் சரிபார்க்க மனிதர்களைப் பயன்படுத்துங்கள். நிராகரிப்பில்தான் மதிப்பு உள்ளது.

Source: https://dev.to/fdjedkdlsspec/ai-assisted-authz-review-reading-permission-boundaries-in-ory-kratos-31cg

Optional learning community: https://t.me/GyaanSetuAi