എസ്.ക്യു.എൽ. ഇഞ്ചക്ഷൻ
ഡേറ്റാബേസ് ഉപയോഗിക്കുന്ന ഒരു കമ്പ്യൂട്ടർ ആപ്ലിക്കേഷന്റെ ബലഹീനത മുതലെടുത്ത് ആപ്ലിക്കേഷൻ ഉദ്ദേശിക്കുന്നതിലും അധികമായിട്ടുള്ള പ്രവൃത്തികൾ ഡേറ്റാബേസിൽ ചെയ്യാൻ ഉപയോഗിക്കുന്ന കോഡ് ഇൻജക്ഷൻ മാർഗ്ഗമാണ് എസ്.ക്യു.എൽ. ഇൻജക്ഷൻ. വെബ്‌സൈറ്റുകളാണ് എസ്.ക്യു.എൽ. ഇൻജക്ഷൻ ആക്രമണങ്ങൾക്ക് അധികവും വിധേയമാകുന്നത്. ഉപയോഗിക്കുന്നവരുടെ ഇൻപുട്ടുകൾ ഡേറ്റാബേസിൽ ഉൾപ്പെടുത്തുന്നതിനു മുമ്പ് വേണ്ടവിധം അരിച്ചെടുക്കാത്തതോ, ആപ്ലിക്കേഷനുകൾ സ്ട്രോങ് ടൈപ്പ് രീതി അനുവർത്തിക്കാത്തതുകൊണ്ടോ എസ്.ക്യു.എൽ. ഇൻജക്ഷൻ പ്രാവർത്തികമായേക്കാം. പി.എച്ച്.പി. പോലുള്ള ഭാഷകൾ സ്വതേ ദുർബല ടൈപ്പിങ് പിന്തുടരുന്നതിനാൽ അശ്രദ്ധമൂലം, ദുർബലമായ ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കപ്പെട്ടേക്കാം. എസ്.ക്യു.എൽ. ഇൻജക്ഷൻ യഥാർത്ഥത്തിൽ ഡേറ്റാബേസിന്റെ ദുർബലതയല്ല, മറിച്ച് ഡേറ്റാബേസ് ഉപയോഗിക്കുന്ന ആപ്ലിക്കേഷന്റെ ദൗർബല്യം മുതലെടുത്ത് ഐച്ഛിക എസ്.ക്യു.എൽ. ക്വറികൾ ഡേറ്റാബേസിൽ പ്രവർത്തിപ്പിക്കാൻ കഴിയുന്നതുമൂലമുള്ള ഭീഷണിയാണ്.
മണിക്കൂറിൽ 71 എസ്.ക്യു.എൽ. ഇൻജക്ഷൻ ആക്രമണങ്ങൾ ഉണ്ടാകുന്നതായി കണക്കാക്കപ്പെട്ടിട്ടുണ്ട്[1] .
വിവിധ മാർഗ്ഗങ്ങൾ
തിരുത്തുകതെറ്റായ വിധത്തിൽ അരിച്ചെടുക്കുന്ന എസ്കേപ്പ് കാരക്ടറുകൾ
തിരുത്തുകഇത്തരത്തിലുള്ള എസ്.ക്യു.എൽ. ഇൻജക്ഷൻ സാദ്ധ്യമാക്കുന്നത് ഉപയോക്താവ് നൽകുന്ന വിവരങ്ങളിലെ എസ്കേപ്പ് കാരക്ടറുകൾ, ആപ്ലിക്കേഷൻ എസ്.ക്യു.എൽ. സ്റ്റേറ്റ്മെന്റ് ആക്കി മാറ്റുന്നതിനു മുമ്പ് അരിച്ചുമാറ്റാത്തതുമൂലമാണ്. ഇത് ആപ്ലിക്കേഷന്റെ ഉപയോക്താവിന് ഡേറ്റാബേസിൽ സ്റ്റേറ്റ്മെന്റുകൾ പ്രവർത്തിക്കാൻ അവസരം നൽകുന്നു.
താഴെ നൽകുന്ന കോഡ് ഒരു അപകടസാദ്ധ്യത ഉൾക്കൊള്ളുന്നു:
statement = "SELECT * FROM users WHERE name = '" + userName + "';"
ഈ എസ്.ക്യു.എൽ കോഡ് "users" എന്ന ടേബിളിൽ നിന്നും നൽകുന്ന ഉപയോക്തൃനാമത്തിന്റെ "(name) വിവരങ്ങൾ എടുക്കാനുള്ളതാണ്. എന്നാൽ ആക്രമണ മനോസ്ഥിതിയുള്ള ഉപയോക്താവിന് "userName" എന്ന ചരത്തിന്റെ വില പ്രത്യേകമായി സൃഷ്ടിച്ച്, കോഡ് എഴുതിയയാൾ ഉദ്ദേശിച്ചതിലുമധികം പ്രവർത്തങ്ങൾ ചെയ്യുന്ന എസ്.ക്യു.എൽ. സ്റ്റേറ്റ്മെന്റ് പ്രവർത്തിപ്പിക്കാൻ കഴിയും. ഉദാഹരണത്തിന് "userName" ചരം സജ്ജീകരിക്കാവുന്ന മാർഗ്ഗങ്ങൾ നൽകുന്നു:
' or '1'='1
അല്ലെങ്കിൽ ക്വറിയുടെ ബാക്കിഭാഗം മറയ്ക്കാൻ പ്രാപ്തമായ വിധത്തിലുള്ള കമന്റ് സൗകര്യവും ഉൾപ്പെടുത്താവുന്നതാണ് (മൂന്ന് വിധത്തിലുള്ള എസ്.ക്യു.എൽ. കമന്റുകൾ ഉണ്ട്):[2]
' or '1'='1' -- '
' or '1'='1' ({ '
' or '1'='1' /* '
ഇത് ഇനിക്കൊടുക്കുന്നവയിൽ ഏതെങ്കിലുമൊരു എസ്.ക്യു.എൽ. സ്റ്റേറ്റ്മെന്റ് സൃഷ്ടിക്കുന്നു:
SELECT * FROM users WHERE name = '' or '1'='1';
SELECT * FROM users WHERE name = '' or '1'='1' -- ';
ഈ കോഡ് പ്രവർത്തിപ്പിക്കുന്ന പക്ഷം, '1'='1' എല്ലായ്പ്പോഴും ശരിയായിരിക്കുന്നതിനാൽ, ഡേറ്റാബേസ് വിവരങ്ങൾ നൽകുന്നതാണ്.
താഴെക്കൊടുത്തിരിക്കുന്ന സ്റ്റേറ്റ്മെന്റിലെ "userName" ചരം, ഒന്നിലധികം സ്റ്റേറ്റ്മെന്റുകൾക്കുള്ള എ.പി.ഐ. ദുരുപയോഗം ചെയ്ത് ഉപയോഗിച്ചാൽ, "users" എന്ന ടേബിൾ മായ്ക്കാനും അതുപോലെ "userinfo" എന്ന ടേബിളിലെ എല്ലാ വിവരങ്ങളും ലഭിക്കാനും കാരണമായേക്കാം:
a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't
ഇത് അന്തിമ എസ്.ക്യു.എൽ. സ്റ്റേറ്റ്മെന്റിനുള്ള കളമൊരുക്കുന്നു::
SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';
മിക്ക എസ്.ക്യു.എൽ. സെർവർ സൗകര്യങ്ങളും ഒന്നിലധികം സ്റ്റേറ്റ്മെന്റുകൾ ഒരു വിളി വഴി പ്രവർത്തിപ്പിക്കാനുള്ള മാർഗ്ഗങ്ങൾ സജ്ജമാക്കിയിട്ടുണ്ട്. എന്നാൽ ചില എസ്.ക്യു.എൽ. എ.പി.ഐ.കൾ, ഉദാഹരണത്തിന് പി.എച്ച്.പി.യുടെ mysql_query(); ഫങ്ഷൻ പോലുള്ളവ സുരക്ഷാകാരണങ്ങളാൽ ഇതനുവദിക്കണമെന്നില്ല. ഇത് പരസ്പരം വളരെ വ്യത്യസ്തമായ ക്വറികൾ ഇൻജക്റ്റ് ചെയ്യുന്നതിൽ നിന്ന് ആക്രമണോദ്ദേശത്തോടെയെത്തുന്നവർക്ക് തടസ്സമാകുന്നുണ്ടെങ്കിലും, ക്വറികളിൽ മാറ്റം വരുത്തുന്നതിന് പൂർണ്ണമായി തടയിടാനായിട്ടില്ല.
തെറ്റായ ടൈപ്പ് ഹാൻഡ്‌ലിങ്
തിരുത്തുകഉപയോക്താവിന് ഉപയോഗിക്കാനുള്ള ഫീൽഡ് സ്ട്രോങ്ലി ടൈപ്പ്ഡ് അല്ലെങ്കിലോ ഡേറ്റാടൈപ്പ് മാനദണ്ഡങ്ങൾ പാലിക്കുന്നുണ്ടോയെന്ന് പരിശോധിക്കാത്തതിനാലോ ആണ് ഇത്തരത്തിലുള്ള എസ്.ക്യു.എൽ. ഇൻജക്ഷൻ സാദ്ധ്യമാവുക. എസ്.ക്യു.എൽ. സ്റ്റേറ്റ്മെന്റിൽ ഉപയോഗിക്കേണ്ട സംഖ്യകൾ എടുക്കേണ്ട ഫീൽഡിൽ, സംഖ്യ തന്നെയാണോ എഴുതി നൽകുന്നതെന്ന് പരിശോധിക്കുന്നില്ലെങ്കിൽ ഇത്തരത്തിലുള്ള ആക്രമണം സാദ്ധ്യമായേക്കും. ഉദാഹരണത്തിന്:
statement := "SELECT * FROM userinfo WHERE id = " + a_variable + ";"
എഴുതിയയാൾ ഉദ്ദേശിച്ചത് a_variable എന്നത് "id" ഫീൽഡിനായി നൽകേണ്ടുന്ന സംഖകളാണെങ്കിലും, അതൊരു സ്ട്രിങ് ആണെന്നിരിക്കെ ഉപയോക്താവിന് സ്റ്റേറ്റ്മെന്റിൽ ദോഷകരങ്ങളായ മാറ്റങ്ങൾ വരുത്താൻ സാധിച്ചേക്കാം. ഉദാഹരണത്തിന് a_variable ഇങ്ങനെ സജ്ജീകരിക്കവുന്നതാണ്:
1;DROP TABLE users
ഇത് എസ്.ക്യു.എൽ. ഇനിക്കൊടുക്കുന്നവിധത്തിൽ മാറ്റുന്നതിനാൽ ഡേറ്റാബേസിൽ നിന്നും "users" എന്ന ടേബിൾ മായ്ക്കുന്നതാണ്:
SELECT * FROM userinfo WHERE id=1;DROP TABLE users;
ബ്ലൈൻഡ് എസ്.ക്യു.എൽ. ഇൻജക്ഷൻ
തിരുത്തുകഒരു വെബ് ആപ്ലിക്കേഷൻ എസ്.ക്യു.എൽ. ഇൻജക്ഷൻ ആക്രമണത്തിനെതിരെ ദുർബലമാണെന്നിരിക്കിലും, ഇൻജക്ഷന്റെ ഫലങ്ങൾ ആക്രമിക്കുന്നയാൾക്ക് കാണത്തില്ലാതിരിക്കുന്ന അവസ്ഥയ്ക്കാണ് ബ്ലൈൻഡ് എസ്.ക്യു.എൽ. ഇൻജക്ഷൻ എന്നു പറയുന്നത്. ദുർബലമായ താൾ ഫലങ്ങൾ പ്രദർശിപ്പിച്ചില്ലെങ്കിലും, ഫലങ്ങൾക്കനുസരിച്ച് വ്യത്യസ്തമായി രൂപപ്പെട്ടേക്കാം. ലഭിക്കുന്ന ഓരോ വിവരത്തിനുമനുസരിച്ച് സ്റ്റേറ്റ്മെന്റിൽ മാറ്റം വരുത്തേണ്ടതുണ്ടെന്നതിനാൽ ഇത്തരം ആക്രമണങ്ങൾ കൂടുതൽ സമയമെടുത്തേക്കാം. എന്നാൽ, ഒരിക്കൽ ദുർബലാവസ്ഥയും, ദുർബലാവസ്ഥയുള്ള സ്ഥാനവും, ലക്ഷ്യമിടുന്ന വിവരങ്ങളും സംഘടിപ്പിക്കാൻ കഴിഞ്ഞാൽ, ബാക്കി കാര്യങ്ങൾ യാന്ത്രികമായി ചെയ്യാനുള്ള നിരവധി ഉപകരണങ്ങൾ ഇന്ന് ലഭ്യമാണ്[3].
സോപാധിക പ്രതികരണങ്ങൾ
തിരുത്തുകഒരു ഡേറ്റാബേസിലെ, ഒരു ടേബിളിൽ നിന്നുള്ള വ്യത്യസ്ത ഫലങ്ങൾ ആപ്ലിക്കേഷൻ പ്രത്യക്ഷപ്പെടുന്ന വിധത്തിൽ വ്യത്യാസമുണ്ടാക്കിയേക്കാം. ഉദാഹരണത്തിന് താഴെക്കൊടുക്കുന്ന രണ്ട് ക്വറികൾ കണക്കിലെടുക്കുക:
SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND '1'='1';
SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND '1'='2';
രണ്ട് ക്വറികളും രണ്ട് ഫലങ്ങളാണ് തരികയെന്ന് നിസ്സംശയം പറയാം. ക്വറികളിലെ "bookId" നിലവിലുണ്ടെങ്കിൽ ആദ്യക്വറി ശരി ("true") എന്ന് വ്യാഖ്യാനിക്കാവുന്ന ഫലം തരികയും അതിനനുസരിച്ച് ആപ്ലിക്കേഷന്റെ രൂപത്തിൽ മാറ്റമുണ്ടാവുകയും ചെയ്യാം (ഉദാ: പശ്ചാത്തലം പച്ചയാകുന്നു). രണ്ടാമത്തെ ക്വറി മിക്കവാറും തെറ്റ് ("false") എന്ന് വ്യാഖ്യാനിക്കാവുന്ന ഫലമാവും തരിക. ആപ്ലിക്കേഷനിൽ മാറ്റമൊന്നുമുണ്ടാകുന്നില്ലെന്ന് കരുതുക. ഫലങ്ങളിൽ നിന്ന് ആക്രമണകാരിക്ക് ഇവിടെ എസ്.ക്യു.എൽ. ഇൻജക്ഷൻ സാദ്ധ്യമാണെന്ന വിവരം ലഭിക്കുന്നതാണ്[4]. ഇത് നടപ്പിലാക്കാൻ കൗശലബുദ്ധിയാവശ്യമാണ്. യഥാർത്ഥ ക്വറി ലളിതമാണെങ്കിൽ ഈ പ്രവൃത്തിയും ലളിതമായിരിക്കും, എന്നാൽ യഥാർത്ഥ ക്വറി സങ്കീർണ്ണമാണെങ്കിൽ പ്രതികരണം കണ്ടെത്തലും സങ്കീർണ്ണമായിത്തീരും.
അവലംബം
തിരുത്തുക- ↑ "SQL Injection: By The Numbers". Imperva.com. 20 സെപ്റ്റംബർ 2011. Retrieved 1 ഡിസംബർ 2012.
- ↑ IBM Informix Guide to SQL: Syntax. Overview of SQL Syntax > How to Enter SQL Comments, IBM
- ↑ "Using SQLBrute to brute force data from a blind SQL injection point". Justin Clarke. Archived from the original on 2008-06-14. Retrieved October 18, 2008.
- ↑ Ofer Maor and Amichai Shulman. "Blind SQL Injection: Getting the syntax right". Imperva. Retrieved September 18, 2008.