ബിസിനസ് ലോജിക് അറ്റാക്കുകൾ വിശദീകരിക്കുന്നു
പണം മോഷ്ടിക്കാൻ അക്രമികൾ എപ്പോഴും നിങ്ങളുടെ കോഡ് തകർക്കണമെന്നില്ല.
പല ഡെവലപ്പർമാരും API-കളും എൻക്രിപ്ഷനും സുരക്ഷിതമാക്കാൻ മാസങ്ങൾ ചിലവഴിക്കുന്നു. അവർ SQL injection അല്ലെങ്കിൽ XSS തടയുന്നതിലാണ് ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നത്. എന്നാൽ ഒരു സെക്യൂരിറ്റി കൺട്രോളും തകർക്കാതെ തന്നെ ഒരു അക്രമിക്കായിക്ക് പണം മോഷ്ടിക്കാൻ സാധിച്ചേക്കാം.
ഇതാണ് ഒരു ബിസിനസ് ലോജിക് അറ്റാക്ക് (Business logic attack).
ആപ്ലിക്കേഷൻ രൂപകൽപ്പന ചെയ്തതുപോലെ തന്നെ പ്രവർത്തിക്കുന്നു. അക്രമികൾ നിങ്ങളുടെ തന്നെ നിയമങ്ങൾ നിങ്ങൾക്ക് എതിരെ ഉപയോഗിക്കുന്നു എന്ന് മാത്രം.
ഒരു ബാങ്ക് ലോക്കർ (vault) സങ്കൽപ്പിക്കുക. മിക്ക സുരക്ഷാ പരിശോധനകളും വാതിൽ ശക്തമാണോ എന്നാണ് പരിശോധിക്കുന്നത്. എന്നാൽ ബിസിനസ് ലോജിക് ടെസ്റ്റിംഗ് മറ്റൊരു ചോദ്യമാണ് ചോദിക്കുന്നത്. ആരെങ്കിലും കാവൽക്കാരനെ വിശ്വസിപ്പിച്ച് വാതിൽ തുറപ്പിക്കുകയാണെങ്കിലോ?
ലോക്കർ കൃത്യമായി പ്രവർത്തിക്കുന്നു. എന്നാൽ പ്രക്രിയ പരാജയപ്പെടുന്നു.
ബാങ്കിംഗ് ലോജിക് അക്രമികൾ ദുരുപയോഗം ചെയ്യുന്ന മൂന്ന് രീതികൾ താഴെ പറയുന്നവയാണ്:
വെയിറ്റിംഗ് പീരിയഡുകൾ മറികടക്കുക (Bypassing Waiting Periods) പുതിയൊരു സ്വീകർത്താവിനെ (recipient) ചേർത്തു കഴിഞ്ഞാൽ ബാങ്കുകൾ പലപ്പോഴും 24 മണിക്കൂർ കാത്തിരിക്കാൻ ആവശ്യപ്പെടാറുണ്ട്. ഇത് പെട്ടെന്നുള്ള മോഷണം തടയാൻ വേണ്ടിയാണ്. എന്നാൽ ഈ പരിശോധന ഒഴിവാക്കുന്ന ഒരു API endpoint അക്രമിക്കായിക്ക് കണ്ടെത്താൻ കഴിഞ്ഞേക്കാം. അവർ UI നിയന്ത്രണങ്ങൾ മറികടന്ന് പണം ഉടനടി കൈമാറുന്നു.
ഇടപാട് പരിധികൾ ലംഘിക്കുക (Breaking Transaction Limits) ഒരു ബാങ്ക് പ്രതിദിന പരിധി 50,000 എന്ന് നിശ്ചയിച്ചിട്ടുണ്ടാകാം. കോഡ് ഓരോ ഇടപാടും വ്യക്തിഗതമായി മാത്രം പരിശോധിക്കുകയാണെങ്കിൽ, അക്രമിക്കായിക്ക് 49,000 രൂപ വീതം അഞ്ച് തവണ കൈമാറാൻ സാധിക്കും. ഓരോ ഇടപാടും ശരിയാണെന്ന് തോന്നും. ആകെ തുക പരിധി കവിഞ്ഞാലും സിസ്റ്റത്തിന് അത് കണ്ടെത്താൻ കഴിയില്ല.
റിവാർഡ് ദുരുപയോഗം (Reward Abuse) പല ആപ്പുകളും ബിൽ പേയ്മെന്റുകൾക്ക് ക്യാഷ്ബാക്ക് നൽകാറുണ്ട്. ഒരു അക്രമിക്കായിക്ക് ഒരു ബിൽ അടച്ച ശേഷം ഉടൻ തന്നെ അത് റദ്ദാക്കിയേക്കാം. സിസ്റ്റം ആ റിവാർഡ് തിരികെ എടുത്തില്ലെങ്കിൽ, അനന്തമായ ക്യാഷ്ബാക്ക് ശേഖരിക്കാൻ അക്രമിക്കായിക്ക് സാധിക്കും.
എന്തുകൊണ്ടാണ് ഓട്ടോമേറ്റഡ് സ്കാനറുകൾ ഇത് തിരിച്ചറിയാത്തത്?
സ്കാനറുകൾ മാൽവെയർ അല്ലെങ്കിൽ ഇൻജക്ഷൻ പോലുള്ള സാങ്കേതിക പിഴവുകളാണ് തിരയുന്നത്. ഒരു ഇടപാട് വിജയകരമായി നടന്നാൽ സ്കാനർ 200 OK എന്ന സ്റ്റാറ്റസ് നൽകുന്നു. എല്ലാം ശരിയാണെന്ന് അത് കരുതുന്നു.
ഒരു ഹ്യൂമൻ ടെസ്റ്റർ ചോദിക്കുന്നത് ഇതാണ്: ഈ ഇടപാട് നടക്കേണ്ട ആവശ്യമുണ്ടായിരുന്നോ?
ഇത്തരം പിഴവുകൾ കണ്ടെത്താൻ, ഒരു ഫീച്ചർ ഹാക്ക് ചെയ്യാൻ കഴിയുമോ എന്ന് ചോദിക്കുന്നത് നിർത്തുക. പകരം, ഒരു ഫീച്ചർ ദുരുപയോഗം ചെയ്യാൻ കഴിയുമോ എന്ന് ചോദിച്ചു തുടങ്ങുക.
ഈ കാര്യങ്ങൾ പരിശോധിക്കുക:
- ഉപയോക്താക്കൾക്ക് വെരിഫിക്കേഷൻ ഘട്ടങ്ങൾ ഒഴിവാക്കാൻ കഴിയുമോ?
- ഉപയോക്താക്കൾക്ക് ഒരു ഐഡിയുടെ ഉടമസ്ഥാവകാശം മാറ്റാൻ കഴിയുമോ?
- API വഴി വെയിറ്റിംഗ് പീരിയഡുകൾ മറികടക്കാൻ കഴിയുമോ?
- പരിധികൾ നിശ്ചയിച്ചിരിക്കുന്നത് ആകെ തുകയ്ക്കാണോ അതോ ഓരോ ക്ലിക്കിനും മാത്രമാണോ?
- റിവാർഡുകൾ ഒന്നിലധികം തവണ ലഭിക്കാൻ സാധ്യതയുണ്ടോ?
മികച്ച സെക്യൂരിറ്റി ടീമുകൾ വെറും use cases മാത്രമല്ല നിർമ്മിക്കുന്നത്. അവർ abuse cases-ഉം നിർമ്മിക്കുന്നു.
"ഉപയോക്താവ് പണം കൈമാറുന്നു" എന്ന് ടെസ്റ്റ് ചെയ്യുന്നതിന് പകരം, "പരിധികൾ മറികടക്കാൻ അക്രമിക്കായി 500 ചെറിയ ഇടപാടുകൾ നടത്താൻ ശ്രമിക്കുന്നു" എന്ന് ടെസ്റ്റ് ചെയ്യുക.
രണ്ടാമത്തെ ചോദ്യമാണ് യഥാർത്ഥ റിസ്ക് കണ്ടെത്തുന്നത്.
Source: https://dev.to/arashad_dodhiya_0e4bdba5a/business-logic-attacks-explained-using-a-banking-app-27hj