𝗜 𝗔𝘂𝗱𝗶𝘁𝗲𝗱 𝗠𝘆 𝗦𝗶𝗱𝗲 𝗣𝗿𝗼𝗷𝗲𝗰𝘁𝘀 𝗳𝗼𝗿 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 — 𝗛𝗲𝗿𝗲 𝗜𝘀 𝗪𝗵𝗮𝘁 𝗜 𝗙𝗼𝘂𝗻𝗱
അടുത്തിടെ ഞാൻ എന്റെ എല്ലാ സൈഡ് പ്രോജക്റ്റുകളും ഓഡിറ്റ് ചെയ്തു. എന്റെ FastAPI ബാക്കെൻഡുകൾ, ടെലിഗ്രാം ബോട്ടുകൾ, വെബ് ആപ്പുകൾ എന്നിവ ഞാൻ പരിശോധിച്ചു. ഞാൻ വളരെ ശ്രദ്ധാലുവാണ് എന്നാണ് ഞാൻ കരുതിയിരുന്നത്.
ഞാൻ തെറ്റിദ്ധരിച്ചു.
പ്രൊഡക്ഷനിൽ (production) നേരിട്ട് എത്തിച്ച യഥാർത്ഥ ബഗുകൾ (bugs) ഞാൻ കണ്ടെത്തി. ഇവ വെറും സിദ്ധാന്തപരമായ പ്രശ്നങ്ങളല്ല. വേഗത്തിൽ കാര്യങ്ങൾ ചെയ്തുതീർക്കാൻ ശ്രമിക്കുന്നതിനിടയിൽ ഞാൻ വരുത്തിയ തെറ്റുകളാണിവ.
ഞാൻ കണ്ടെത്തിയ പ്രധാന പ്രശ്നങ്ങളും അവ പരിഹരിക്കാനുള്ള വഴികളും താഴെ പറയുന്നവയാണ്:
- കണ്ടിഷണൽ ഓതന്റിക്കേഷൻ (Conditional Authentication) ഒരു സീക്രട്ട് (secret) ഉണ്ടെങ്കിൽ മാത്രം API കീകൾ പരിശോധിക്കുന്ന രീതിയിലുള്ള കോഡാണ് ഞാൻ എഴുതിയിരുന്നത്. എൻവയോൺമെന്റിൽ (environment) സീക്രട്ട് സെറ്റ് ചെയ്യാൻ മറന്നുപോയാൽ, ആ പരിശോധന പൂർണ്ണമായും ഒഴിവാക്കപ്പെടും. ഇത് എന്റെ API എല്ലാവർക്കും ലഭ്യമാകുന്ന അവസ്ഥയുണ്ടാക്കി.
- പരിഹാരം: ഓതന്റിക്കേഷൻ ഒരിക്കലും കണ്ടിഷണൽ ആക്കരുത്. സീക്രട്ട് ഇല്ലെങ്കിൽ, ആപ്പ് ഒരു എറർ (error) കാണിക്കുകയും പ്രവർത്തനം നിർത്തുകയും വേണം.
- Git ഹിസ്റ്ററിയിലൂടെ കീകൾ ചോരുന്നത് എന്റെ Git ഹിസ്റ്ററിയിൽ പഴയ API കീകൾ ഞാൻ കണ്ടെത്തി. പിന്നീട് ഞാൻ അവ .env ഫയലുകളിലേക്ക് മാറ്റിയിരുന്നു, എന്നാൽ Git നിങ്ങളുടെ കോഡിന്റെ ഓരോ പഴയ പതിപ്പും എന്നെന്നേക്കുമായി സൂക്ഷിക്കുന്നു.
- പരിഹാരം: Git-ലേക്ക് ഒരിക്കൽ എത്തിച്ച ഏതൊരു കീയും സുരക്ഷാ ഭീഷണി നേരിട്ടതായി കണക്കാക്കുക. അത് ഉടൻ തന്നെ റദ്ദാക്കുക (revoke). നിങ്ങളുടെ ഹിസ്റ്ററി വൃത്തിയാക്കാൻ git-filter-repo പോലുള്ള ടൂളുകൾ ഉപയോഗിക്കുക.
- ബാക്കിയായ ഡീബഗ് എൻഡ്പോയിന്റുകൾ (Debug Endpoints) ഡാറ്റാബേസ് കോൺഫിഗറേഷനും സിസ്റ്റം സെറ്റിംഗുകളും കാണിക്കുന്ന എൻഡ്പോയിന്റുകൾ ഞാൻ പ്രൊഡക്ഷനിൽ അവശേഷിപ്പിച്ചു. ഇവ ഡെവലപ്മെന്റ് സമയത്ത് സഹായകരമാണെങ്കിലും യഥാർത്ഥ ഉപയോഗത്തിൽ (in the wild) അപകടകരമാണ്.
- പരിഹാരം: നിങ്ങളുടെ ഡിപ്ലോയ്മെന്റ് ചെക്ക്ലിസ്റ്റിൽ (deployment checklist) ഡീബഗ് എൻഡ്പോയിന്റുകൾ നീക്കം ചെയ്യുക എന്നതും ഉൾപ്പെടുത്തുക.
- വിശദമായ എറർ മെസ്സേജുകൾ (Verbose Error Messages) സിസ്റ്റത്തിൽ നിന്നുള്ള നേരിട്ടുള്ള എററുകൾ (raw system errors) ഞാൻ ഉപയോക്താവിന് നൽകുന്നുണ്ടായിരുന്നു. ഈ എററുകൾ നിങ്ങളുടെ ഫയൽ പാത്തുകൾ, ഡാറ്റാബേസ് തരങ്ങൾ, ലൈബ്രറി പതിപ്പുകൾ എന്നിവ വെളിപ്പെടുത്തുന്നു. ഒരു അറ്റാക്കർക്ക് (attacker) നിങ്ങളുടെ സിസ്റ്റത്തെ ലക്ഷ്യം വെക്കാൻ ഈ വിവരങ്ങൾ ഉപയോഗിക്കാം.
- പരിഹാരം: പൂർണ്ണമായ എറർ വിവരങ്ങൾ നിങ്ങൾക്ക് വേണ്ടി ആന്തരികമായി (internally) ലോഗ് ചെയ്യുക. ക്ലയന്റിന് ഒരു പൊതുവായ "Internal Server Error" സന്ദേശം മാത്രം നൽകുക.
- innerHTML വഴിയുള്ള XSS എന്റെ ഫ്രണ്ട്എൻഡിൽ ഉപയോക്താക്കളുടെ ഡാറ്റ കാണിക്കാൻ ഞാൻ innerHTML ഉപയോഗിച്ചു. ഇത് അറ്റാക്കർമാർക്ക് നിങ്ങളുടെ സൈറ്റിലേക്ക് സ്ക്രിപ്റ്റുകൾ ഇൻജക്ട് ചെയ്യാൻ (inject) അനുവദിക്കുന്നു.
- പരിഹാരം: ഡാറ്റ എപ്പോഴും സാനിറ്റൈസ് (sanitize) ചെയ്യുക അല്ലെങ്കിൽ innerHTML-ന് പകരം textContent ഉപയോഗിക്കുക.
- റേറ്റ് ലിമിറ്റിംഗിന്റെ അഭാവം (Lack of Rate Limiting) പരിധികളില്ലാതെ വിലകൂടിയ AI മോഡലുകളെ വിളിക്കുന്ന എൻഡ്പോയിന്റുകൾ എനിക്കുണ്ടായിരുന്നു. ഒരു ഉപയോക്താവിന് മിനിറ്റുകൾക്കുള്ളിൽ വലിയൊരു ബില്ല് ഉണ്ടാക്കാൻ ഇതിലൂടെ സാധിക്കും.
- പരിഹാരം: ഓതന്റിക്കേഷൻ അനധികൃത ഉപയോക്താക്കളെ തടയുന്നു. റേറ്റ് ലിമിറ്റിംഗ് എന്നത് അംഗീകൃത ഉപയോക്താക്കൾ നിങ്ങളുടെ സിസ്റ്റം ദുരുപയോഗം ചെയ്യുന്നത് തടയുന്നു. നിങ്ങൾക്ക് ഇവ രണ്ടും ആവശ്യമാണ്.
- അനുവദനീയമായ CORS സെറ്റിംഗുകൾ (Permissive CORS Settings)
എന്റെ മിഡിൽവെയറിൽ (middleware) ഞാൻ
allow_origins=["*"]ഉപയോഗിച്ചു. ഇത് ഏതൊരു വെബ്സൈറ്റിനും നിങ്ങളുടെ API-ലേക്ക് റിക്വസ്റ്റുകൾ അയക്കാൻ അനുവദിക്കുന്നു.
- പരിഹാരം: പ്രൊഡക്ഷനിൽ നിങ്ങളുടെ പ്രത്യേക ഡൊമെയ്നുകളെ (domains) മാത്രം അനുവദിക്കുക.
- ഫയൽ ചോർച്ച താൽക്കാലിക ഫയലുകൾ സൃഷ്ടിക്കുന്ന രീതിയിൽ ഞാൻ കോഡ് എഴുതിയിരുന്നു, എന്നാൽ പ്രോസസ്സ് ക്രാഷ് ആയാൽ അവ ഡിലീറ്റ് ചെയ്യാൻ സാധിച്ചില്ല. ഈ ഫയലുകൾ നിങ്ങളുടെ സെർവറിൽ എന്നെന്നേക്കുമായി അവശേഷിക്കും.
- പരിഹാരം: ഒരു എറർ സംഭവിച്ചാലും ഫയലുകൾ ഡിലീറ്റ് ചെയ്യപ്പെടുന്നുണ്ടെന്ന് ഉറപ്പാക്കാൻ ഒരു try-finally ബ്ലോക്ക് ഉപയോഗിക്കുക.
സുരക്ഷാ പ്രശ്നങ്ങൾ അപൂർവ്വമായേ മനഃപൂർവ്വം സംഭവിക്കാറുള്ളൂ. "ഞാൻ ഇത് പിന്നീട് ശരിയാക്കാം" എന്ന് പറയുന്നതിന്റെ ഫലമായാണ് അവ ഉണ്ടാകുന്നത്. ആ 'പിന്നീട്' ഒരിക്കലും വരാറില്ല.
ആദ്യ ദിവസം മുതൽ തന്നെ നിങ്ങളുടെ വർക്ക്ഫ്ലോയിൽ സുരക്ഷ ഉൾപ്പെടുത്തുക. കോഡ് കമിറ്റ് ചെയ്യുന്നതിനും ഡെപ്ലോയ് ചെയ്യുന്നതിനും മുമ്പ് അത് പരിശോധിക്കുക.
സ്രോതസ്സ്: https://dev.to/justjinoit/i-audited-my-own-side-projects-for-security-issues-heres-what-i-found-1ahb