AI-సహాయక AuthZ రివ్యూ: Ory Kratosలో Permission Boundariesని చదవడం

AI బగ్‌లను కనుగొనడంలో అంతగా సమర్థవంతమైనది కాదు, కానీ అనుమానాలను కలిగించడంలో అది అద్భుతమైనది.

సెక్యూరిటీ రంగంలో, AI చేయగలిగే అత్యంత తక్కువ ఖర్చుతో కూడిన పని ఏమిటంటే, తప్పుడు రిపోర్టుల వరదను సృష్టించడం. అందుకే బగ్ బౌంటీ ప్రోగ్రామ్‌లు తమ నిబంధనలను నిలిపివేస్తున్నాయి లేదా కఠినతరం చేస్తున్నాయి.

నేను AIని భిన్నంగా ఉపయోగిస్తాను. నా AuthZ Smell Catalog ఆధారంగా AIని ఎక్కువ పరిమాణంలో పరికల్పనలను (hypotheses) రూపొందించనిస్తాను. ఆ తర్వాత, కష్టమైన పనిని నేనే చేస్తాను. ఆ పరికల్పనలను తప్పు అని నిరూపించడమే (kill) నా పని.

విజయవంతమైన రివ్యూ అంటే బగ్‌ల జాబితా కాదు. అది పరీక్షలో విఫలమైన ఆలోచనల యొక్క 'కిల్ టేబుల్' (kill table).

నేను Ory Kratos సోర్స్ కోడ్‌ను రివ్యూ చేశాను. Kratos ఐడెంటిటీ మరియు యూజర్ మేనేజ్‌మెంట్‌ను నిర్వహిస్తుంది. ఇది మల్టిపుల్ ఐడెంటిటీలు మరియు పబ్లిక్ APIలను ఉపయోగిస్తుంది కాబట్టి, ఇది అత్యంత రిస్క్ ఉన్న విభాగం.

నేను ఐదు పరికల్పనలను పరీక్షించాను:

  • H1: కోడ్‌లో Admin APIకి ఎటువంటి అథరైజేషన్ లేదు.
  • H2: క్రాస్-ఐడెంటిటీ లేదా క్రాస్-టెనెంట్ డేటా లీక్‌లు.
  • H3: రికవరీ ఫ్లోస్‌లో టోకెన్ పునర్వినియోగం (reuse).
  • H4: సెట్టింగ్స్ ఫ్లోస్‌లో ఐడెంటిటీ కన్ఫ్యూజన్.
  • H5: రిక్వెస్ట్ పేలోడ్స్ ద్వారా టెనెంట్ అసైన్‌మెంట్.

ఫలితాలు:

  • H1: నిరాకరించబడింది (KILLED). అథరైజేషన్ నెట్‌వర్క్ బౌండరీ వద్ద ఉంటుంది, కోడ్ హ్యాండ్లర్‌లో కాదు. ఇది డిజైన్ పరంగానే అలా చేయబడింది.
  • H2: నిరాకరించబడింది (KILLED). ఒక సెంట్రల్ డేటా-యాక్సెస్ లేయర్ టెనెంట్ ID ఆధారంగా అన్ని క్వెరీలను ఫిల్టర్ చేస్తుంది. వినియోగదారులు దీనిని దాటవేయలేరు.
  • H3: నిరాకరించబడింది (KILLED). టోకెన్లు ఒకేసారి వాడటానికి (single-use) మరియు నిర్ణీత సమయానికి (time-boxed) పరిమితం చేయబడ్డాయి.
  • H4: నిరాకరించబడింది (KILLED). ఫ్లోస్ సెషన్‌కు అనుసంధానించబడి ఉంటాయి, యూజర్ ఇన్‌పుట్‌కు కాదు.
  • H5: నిరాకరించబడింది (KILLED). టెనెంట్ IDలు సిస్టమ్ కాంటెక్స్ట్ నుండి వస్తాయి, రిక్వెస్ట్ బాడీ నుండి కాదు.

ఐదు పరికల్పనలతో మొదలుపెట్టాను. ఒక్క ఫలితం (finding) కూడా తేలలేదు. ఇదే ఒక విజయవంతమైన రివ్యూ.

మీ సెక్యూరిటీ పని కోసం రెండు పాఠాలు:

  1. డిప్లాయ్‌మెంట్-లేయర్ సెక్యూరిటీ అనేది సెక్యూరిటీ లేనట్లుగా అనిపించవచ్చు. ఒక గార్డ్ నెట్‌వర్క్ స్థాయిలో ఉంటే, కోడ్ రక్షణ లేనట్లుగా కనిపిస్తుంది. మీరు ఆర్కిటెక్చర్‌ను తనిఖీ చేసే వరకు దానిని రిపోర్ట్ చేయకండి.

  2. చోక్‌పాయింట్‌ను (chokepoint) కనుగొనండి. ఒక సిస్టమ్ డేటా లేయర్‌లో బౌండరీలను అమలు చేస్తే, వ్యక్తిగత హ్యాండ్లర్‌లకు తనిఖీలు అవసరం లేదు. "ఈ హ్యాండ్లర్ పర్మిషన్లను తనిఖీ చేస్తుందా?" అని అడగడానికి బదులుగా, "చోక్‌పాయింట్ లేకుండా ఎవరైనా డేటాను చేరుకోగలరా?" అని అడగండి.

అభ్యర్థులను (candidates) తిరస్కరించడానికి AIని ఉపయోగించండి. మిగిలిన వాటిని ధృవీకరించడానికి మనుషులను ఉపయోగించండి. అసలైన విలువ తిరస్కరణలోనే ఉంది.

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

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