🥇വെബ്‌സൈറ്റ് സുരക്ഷയുടെ മാരകമായ പാപങ്ങൾ: വർഷത്തേക്കുള്ള ദുർബലത സ്കാനർ സ്ഥിതിവിവരക്കണക്കുകളിൽ നിന്ന് ഞങ്ങൾ പഠിച്ചത്

ഏകദേശം ഒരു വർഷം മുമ്പ്, ഞങ്ങൾ ഡാറ്റാലൈനിൽ സമാരംഭിച്ചു സേവനം ഐടി ആപ്ലിക്കേഷനുകളിലെ കേടുപാടുകൾ തിരയാനും വിശകലനം ചെയ്യാനും. ക്വാളിസ് ക്ലൗഡ് സൊല്യൂഷൻ അടിസ്ഥാനമാക്കിയുള്ളതാണ് ഈ സേവനം, അതിന്റെ പ്രവർത്തനത്തെക്കുറിച്ച് ഞങ്ങൾ ഇതിനകം പറഞ്ഞു. സൊല്യൂഷനുമായി പ്രവർത്തിച്ച ഒരു വർഷത്തിനിടയിൽ, ഞങ്ങൾ വ്യത്യസ്‌ത സൈറ്റുകൾക്കായി 291 സ്കാനുകൾ നടത്തുകയും വെബ് ആപ്ലിക്കേഷനുകളിലെ പൊതുവായ കേടുപാടുകളെക്കുറിച്ചുള്ള സ്ഥിതിവിവരക്കണക്കുകൾ ശേഖരിക്കുകയും ചെയ്തു.

ചുവടെയുള്ള ലേഖനത്തിൽ, വ്യത്യസ്ത തലത്തിലുള്ള നി സ്കാനർ പലപ്പോഴും എന്തെല്ലാം കേടുപാടുകൾ കണ്ടെത്തി, എന്തുകൊണ്ടാണ് അവ സംഭവിക്കുന്നത്, എങ്ങനെ സ്വയം പരിരക്ഷിക്കാം എന്ന് നോക്കാം.

ക്വാളിസ് എല്ലാ വെബ് ആപ്ലിക്കേഷൻ കേടുപാടുകളെയും മൂന്ന് തലങ്ങളിലുള്ള നിർണായകതകളായി വിഭജിക്കുന്നു: താഴ്ന്ന, ഇടത്തരം, ഉയർന്നത്. "തീവ്രത" പ്രകാരം നിങ്ങൾ വിതരണം നോക്കുകയാണെങ്കിൽ, എല്ലാം അത്ര മോശമല്ലെന്ന് തോന്നുന്നു. ഉയർന്ന തലത്തിലുള്ള വിമർശനാത്മകതയുള്ള കുറച്ച് കേടുപാടുകൾ ഉണ്ട്, മിക്കവാറും എല്ലാം നിർണ്ണായകമല്ലാത്തവയാണ്:

എന്നാൽ വിമർശനാത്മകമല്ലാത്തത് നിരുപദ്രവകരമെന്നല്ല അർത്ഥമാക്കുന്നത്. അവ ഗുരുതരമായ നാശത്തിനും കാരണമാകും.

മുൻനിര "നിർണ്ണായകമല്ലാത്ത" കേടുപാടുകൾ

സമ്മിശ്ര ഉള്ളടക്ക കേടുപാടുകൾ.
എച്ച്ടിടിപിഎസ് പ്രോട്ടോക്കോൾ വഴി ക്ലയന്റിനും സെർവറിനുമിടയിൽ ഡാറ്റ കൈമാറ്റം ചെയ്യുന്നതാണ് വെബ്‌സൈറ്റ് സുരക്ഷയുടെ മാനദണ്ഡം, ഇത് എൻക്രിപ്ഷനെ പിന്തുണയ്ക്കുകയും തടസ്സങ്ങളിൽ നിന്ന് വിവരങ്ങൾ സംരക്ഷിക്കുകയും ചെയ്യുന്നു.

ചില സൈറ്റുകൾ ഉപയോഗിക്കുന്നു സമ്മിശ്ര ഉള്ളടക്കം: ചില ഡാറ്റ സുരക്ഷിതമല്ലാത്ത HTTP പ്രോട്ടോക്കോൾ വഴി കൈമാറുന്നു. ഇത് മിക്കപ്പോഴും കൈമാറുന്നത് ഇങ്ങനെയാണ് നിഷ്ക്രിയ ഉള്ളടക്കം - സൈറ്റിന്റെ പ്രദർശനത്തെ മാത്രം ബാധിക്കുന്ന വിവരങ്ങൾ: ചിത്രങ്ങൾ, css ശൈലികൾ. എന്നാൽ ചിലപ്പോൾ ഇത് ഇങ്ങനെയാണ് പകരുന്നത് സജീവ ഉള്ളടക്കം: സൈറ്റിന്റെ പെരുമാറ്റം നിയന്ത്രിക്കുന്ന സ്ക്രിപ്റ്റുകൾ. ഈ സാഹചര്യത്തിൽ, പ്രത്യേക സോഫ്‌റ്റ്‌വെയർ ഉപയോഗിച്ച്, നിങ്ങൾക്ക് സെർവറിൽ നിന്ന് വരുന്ന സജീവ ഉള്ളടക്കമുള്ള വിവരങ്ങൾ വിശകലനം ചെയ്യാനും ഈച്ചയിൽ നിങ്ങളുടെ പ്രതികരണങ്ങൾ പരിഷ്‌ക്കരിക്കാനും അതിന്റെ സ്രഷ്‌ടാക്കൾ ഉദ്ദേശിച്ചിട്ടില്ലാത്ത രീതിയിൽ മെഷീൻ പ്രവർത്തിക്കാനും കഴിയും.

മിക്സഡ് ഉള്ളടക്കമുള്ള സൈറ്റുകൾ സുരക്ഷിതമല്ലെന്നും ഉള്ളടക്കം ബ്ലോക്ക് ചെയ്യുമെന്നും ബ്രൗസറുകളുടെ പുതിയ പതിപ്പുകൾ ഉപയോക്താക്കൾക്ക് മുന്നറിയിപ്പ് നൽകുന്നു. വെബ്‌സൈറ്റ് ഡെവലപ്പർമാർക്ക് കൺസോളിൽ ബ്രൗസർ മുന്നറിയിപ്പുകളും ലഭിക്കും. ഉദാഹരണത്തിന്, ഇത് ഇങ്ങനെയാണ് കാണപ്പെടുന്നത് ഫയർഫോക്സ്:

എന്താണ് അപകടകരമായത്: ആക്രമണകാരികൾ ഉപയോക്തൃ വിവരങ്ങൾ തടസ്സപ്പെടുത്തുന്നതിനും സ്ക്രിപ്റ്റുകൾ മാറ്റിസ്ഥാപിക്കുന്നതിനും അവന്റെ പേരിൽ സൈറ്റിലേക്ക് അഭ്യർത്ഥനകൾ അയയ്‌ക്കുന്നതിനും ഒരു സുരക്ഷിതമല്ലാത്ത പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുന്നു. ഒരു സൈറ്റ് സന്ദർശകൻ ഡാറ്റ നൽകിയില്ലെങ്കിലും, ഇത് അവനെ സംരക്ഷിക്കില്ല ഫിഷിംഗ് - വഞ്ചനാപരമായ രീതികൾ ഉപയോഗിച്ച് രഹസ്യ വിവരങ്ങൾ നേടുക. ഉദാഹരണത്തിന്, ഒരു സ്ക്രിപ്റ്റ് ഉപയോഗിച്ച്, നിങ്ങൾക്ക് ഉപയോക്താവിന് പരിചിതമായ ഒരു സുരക്ഷിതമല്ലാത്ത സൈറ്റിലേക്ക് ഉപയോക്താവിനെ റീഡയറക്‌ടുചെയ്യാനാകും. ചില സാഹചര്യങ്ങളിൽ, ക്ഷുദ്രകരമായ സൈറ്റ് ഒറിജിനലിനേക്കാൾ മികച്ചതായി കാണപ്പെടുന്നു, കൂടാതെ ഉപയോക്താവിന് സ്വയം ഫോം പൂരിപ്പിച്ച് രഹസ്യ ഡാറ്റ സമർപ്പിക്കാനും കഴിയും.

ഒരു വെബ് ഡെവലപ്പർ ഓർമ്മിക്കേണ്ടത് എന്താണ്: സൈറ്റ് അഡ്‌മിനിസ്‌ട്രേറ്റർ ഒരു SSL/TLS സർട്ടിഫിക്കറ്റ് ഇൻസ്‌റ്റാൾ ചെയ്‌ത് കോൺഫിഗർ ചെയ്‌തിട്ടുണ്ടെങ്കിൽപ്പോലും, മനുഷ്യ പിശക് കാരണം ഒരു അപകടസാധ്യത ഉണ്ടാകാം. ഉദാഹരണത്തിന്, പേജുകളിലൊന്നിൽ നിങ്ങൾ ഒരു ആപേക്ഷിക ലിങ്കല്ല, മറിച്ച് http-യിൽ നിന്നുള്ള ഒരു സമ്പൂർണ്ണ ലിങ്ക് ഇടുകയാണെങ്കിൽ, കൂടാതെ നിങ്ങൾ http-യിൽ നിന്ന് https-ലേക്ക് റീഡയറക്‌ടുകൾ സജ്ജീകരിച്ചിട്ടില്ലെങ്കിൽ.

ഒരു ബ്രൗസർ ഉപയോഗിച്ച് നിങ്ങൾക്ക് സൈറ്റിൽ സമ്മിശ്ര ഉള്ളടക്കം കണ്ടെത്താനാകും: പേജിന്റെ സോഴ്സ് കോഡ് തിരയുക, ഡെവലപ്പർ കൺസോളിൽ അറിയിപ്പുകൾ വായിക്കുക. എന്നിരുന്നാലും, ഡവലപ്പർക്ക് വളരെക്കാലം മടുപ്പോടെ കോഡ് ഉപയോഗിച്ച് ടിങ്കർ ചെയ്യേണ്ടിവരും. സ്വയമേവയുള്ള വിശകലന ഉപകരണങ്ങൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് പ്രക്രിയ വേഗത്തിലാക്കാൻ കഴിയും, ഉദാഹരണത്തിന്: SSL പരിശോധന, സൗജന്യ ലൈറ്റ്ഹൗസ് സോഫ്റ്റ്വെയർ അല്ലെങ്കിൽ പണമടച്ചുള്ള സോഫ്റ്റ്വെയർ സ്ക്രീമിംഗ് ഫ്രോഗ് SEO സ്പൈഡർ.

കൂടാതെ, പാരമ്പര്യമായി ലഭിച്ച ലെഗസി-കോഡ് - കോഡിലെ പ്രശ്നങ്ങൾ കാരണം ഈ അപകടസാധ്യത ഉണ്ടാകാം. ഉദാഹരണത്തിന്, ചില പേജുകൾ ഒരു പഴയ ടെംപ്ലേറ്റ് ഉപയോഗിച്ചാണ് സൃഷ്ടിക്കുന്നതെങ്കിൽ, അത് https എന്നതിലേക്കുള്ള സൈറ്റുകളുടെ പരിവർത്തനം കണക്കിലെടുക്കുന്നില്ല.
"HTTPO മാത്രം", "സുരക്ഷിത" ഫ്ലാഗുകൾ ഇല്ലാത്ത കുക്കികൾ.
ആക്രമണകാരികൾ ഉപയോക്തൃ ഡാറ്റ മോഷ്ടിക്കാൻ ഉപയോഗിക്കുന്ന സ്ക്രിപ്റ്റുകൾ വഴി കുക്കികൾ പ്രോസസ്സ് ചെയ്യുന്നതിൽ നിന്ന് "HTTPO മാത്രം" ആട്രിബ്യൂട്ട് സംരക്ഷിക്കുന്നു. "സുരക്ഷിത" ഫ്ലാഗ് കുക്കികളെ വ്യക്തമായ വാചകത്തിൽ അയയ്ക്കാൻ അനുവദിക്കുന്നില്ല. കുക്കികൾ അയയ്‌ക്കാൻ സുരക്ഷിത HTTPS പ്രോട്ടോക്കോൾ ഉപയോഗിച്ചാൽ മാത്രമേ ആശയവിനിമയം അനുവദിക്കൂ.

രണ്ട് ആട്രിബ്യൂട്ടുകളും കുക്കി പ്രോപ്പർട്ടികളിൽ വ്യക്തമാക്കിയിട്ടുണ്ട്:
```
Set-Cookie: Secure; HttpOnly
```
എന്താണ് അപകടകരമായത്: സൈറ്റ് ഡെവലപ്പർ ഈ ആട്രിബ്യൂട്ടുകൾ വ്യക്തമാക്കിയിട്ടില്ലെങ്കിൽ, ഒരു ആക്രമണകാരിക്ക് കുക്കിയിൽ നിന്ന് ഉപയോക്താവിന്റെ വിവരങ്ങൾ തടസ്സപ്പെടുത്തുകയും അത് ചൂഷണം ചെയ്യുകയും ചെയ്യാം. പ്രാമാണീകരണത്തിനും അംഗീകാരത്തിനുമായി കുക്കികൾ ഉപയോഗിക്കുകയാണെങ്കിൽ, അയാൾക്ക് ഉപയോക്താവിന്റെ സെഷൻ ഹൈജാക്ക് ചെയ്യാനും അവന്റെ പേരിൽ സൈറ്റിൽ പ്രവർത്തനങ്ങൾ നടത്താനും കഴിയും.

ഒരു വെബ് ഡെവലപ്പർ ഓർമ്മിക്കേണ്ടത് എന്താണ്: ഒരു ചട്ടം പോലെ, ജനപ്രിയ ചട്ടക്കൂടുകളിൽ ഈ ആട്രിബ്യൂട്ടുകൾ സ്വയമേവ സജ്ജീകരിച്ചിരിക്കുന്നു. എങ്കിലും വെബ് സെർവർ കോൺഫിഗറേഷൻ പരിശോധിച്ച് ഫ്ലാഗ് സജ്ജീകരിക്കുക: Set-Cookie HttpOnly; സുരക്ഷിത.

ഈ സാഹചര്യത്തിൽ, "HTTPO മാത്രം" ആട്രിബ്യൂട്ട് നിങ്ങളുടെ സ്വന്തം JavaScript-ന് കുക്കികളെ അദൃശ്യമാക്കും.
പാത അടിസ്ഥാനമാക്കിയുള്ള കേടുപാടുകൾ.
പൊതുവായി ആക്‌സസ് ചെയ്യാവുന്ന ഫയലോ വെബ്‌സൈറ്റ് ഡയറക്‌ടറിയോ രഹസ്യസ്വഭാവമുള്ള വിവരങ്ങളോ കണ്ടെത്തിയാൽ സ്കാനർ അത്തരം അപകടസാധ്യത റിപ്പോർട്ട് ചെയ്യുന്നു. ഉദാഹരണത്തിന്, ഇത് വ്യക്തിഗത സിസ്റ്റം കോൺഫിഗറേഷൻ ഫയലുകൾ അല്ലെങ്കിൽ മുഴുവൻ ഫയൽ സിസ്റ്റത്തിലേക്കുള്ള ആക്സസ് കണ്ടെത്തുന്നു. സൈറ്റിൽ ആക്സസ് അവകാശങ്ങൾ തെറ്റായി സജ്ജീകരിച്ചിട്ടുണ്ടെങ്കിൽ ഈ സാഹചര്യം സാധ്യമാണ്.

എന്താണ് അപകടകരമായത്: ഫയൽ സിസ്റ്റം "പുറത്തുനിൽക്കുകയാണെങ്കിൽ", ഒരു ആക്രമണകാരിക്ക് ഓപ്പറേറ്റിംഗ് സിസ്റ്റം ഇന്റർഫേസിലേക്ക് വീഴുകയും അവ വ്യക്തമായ വാചകത്തിൽ സംഭരിച്ചിട്ടുണ്ടെങ്കിൽ പാസ്‌വേഡുകളുള്ള ഫോൾഡറുകൾ കണ്ടെത്താൻ ശ്രമിക്കുകയും ചെയ്യാം (അത് ചെയ്യരുത്!). അല്ലെങ്കിൽ നിങ്ങൾക്ക് പാസ്‌വേഡ് ഹാഷുകൾ മോഷ്ടിക്കാനും പാസ്‌വേഡ് ബ്രൂട്ട് ഫോഴ്‌സ് ചെയ്യാനും കഴിയും, കൂടാതെ സിസ്റ്റത്തിൽ പ്രത്യേകാവകാശങ്ങൾ ഉയർത്താനും ഇൻഫ്രാസ്ട്രക്ചറിലേക്ക് ആഴത്തിൽ നീങ്ങാനും ശ്രമിക്കാം.

ഒരു വെബ് ഡെവലപ്പർ ഓർമ്മിക്കേണ്ടത് എന്താണ്: ആക്സസ് അവകാശങ്ങളെക്കുറിച്ച് മറക്കരുത്, പ്ലാറ്റ്ഫോം, വെബ് സെർവർ, വെബ് ആപ്ലിക്കേഷൻ എന്നിവ കോൺഫിഗർ ചെയ്യുക, അങ്ങനെ അത് വെബ് ഡയറക്ടറിയിൽ നിന്ന് "രക്ഷപ്പെടാൻ" അസാധ്യമാണ്.
സ്വയമേവ പൂരിപ്പിക്കൽ പ്രവർത്തനക്ഷമമാക്കി സെൻസിറ്റീവ് ഡാറ്റ നൽകുന്നതിനുള്ള ഫോമുകൾ.
ഒരു ഉപയോക്താവ് പതിവായി വെബ്‌സൈറ്റുകളിൽ ഫോമുകൾ പൂരിപ്പിക്കുകയാണെങ്കിൽ, അവരുടെ ബ്രൗസർ ഓട്ടോഫിൽ ഫീച്ചർ ഉപയോഗിച്ച് ഈ വിവരങ്ങൾ സംഭരിക്കുന്നു.

വെബ്‌സൈറ്റുകളിലെ ഫോമുകളിൽ പാസ്‌വേഡുകളോ ക്രെഡിറ്റ് കാർഡ് നമ്പറുകളോ പോലുള്ള സെൻസിറ്റീവ് വിവരങ്ങളുള്ള ഫീൽഡുകൾ ഉൾപ്പെട്ടേക്കാം. അത്തരം ഫീൽഡുകൾക്കായി, സൈറ്റിൽ തന്നെ ഫോം ഓട്ടോഫിൽ ഫംഗ്ഷൻ പ്രവർത്തനരഹിതമാക്കുന്നത് മൂല്യവത്താണ്.

എന്താണ് അപകടകരമായത്: ഉപയോക്താവിന്റെ ബ്രൗസർ സെൻസിറ്റീവ് വിവരങ്ങൾ സംഭരിക്കുന്നുവെങ്കിൽ, ഒരു ആക്രമണകാരിക്ക് അത് പിന്നീട് തടയാൻ കഴിയും, ഉദാഹരണത്തിന് ഫിഷിംഗ് വഴി. സാരാംശത്തിൽ, ഈ സൂക്ഷ്മതയെക്കുറിച്ച് മറന്നുപോയ ഒരു വെബ് ഡെവലപ്പർ തന്റെ ഉപയോക്താക്കളെ സജ്ജമാക്കുകയാണ്.

ഒരു വെബ് ഡെവലപ്പർ ഓർമ്മിക്കേണ്ടത് എന്താണ്: ഈ സാഹചര്യത്തിൽ, ഞങ്ങൾക്ക് ഒരു ക്ലാസിക് വൈരുദ്ധ്യമുണ്ട്: സൗകര്യവും സുരക്ഷയും. ഒരു വെബ് ഡെവലപ്പർ ഉപയോക്തൃ അനുഭവത്തെക്കുറിച്ചാണ് ചിന്തിക്കുന്നതെങ്കിൽ, അയാൾക്ക് ബോധപൂർവ്വം സ്വയം പൂർത്തിയാക്കൽ തിരഞ്ഞെടുക്കാനാകും. ഉദാഹരണത്തിന്, പിന്തുടരുന്നത് പ്രധാനമാണെങ്കിൽ വെബ് ഉള്ളടക്ക പ്രവേശനക്ഷമത മാർഗ്ഗനിർദ്ദേശങ്ങൾ - വൈകല്യമുള്ള ഉപയോക്താക്കൾക്കുള്ള ഉള്ളടക്കത്തിന്റെ പ്രവേശനക്ഷമതയ്ക്കുള്ള ശുപാർശകൾ.

മിക്ക ബ്രൗസറുകൾക്കും, നിങ്ങൾക്ക് autocompete="off" ആട്രിബ്യൂട്ട് ഉപയോഗിച്ച് സ്വയം പൂർത്തീകരണം പ്രവർത്തനരഹിതമാക്കാം, ഉദാഹരണത്തിന്:
```
 <body>
    <form action="/ml/form/submit" method="get" autocomplete="off">
      <div>
        <input type="text" placeholder="First Name">
      </div>
      <div>
        <input type="text" id="lname" placeholder="Last Name" autocomplete="on">
      </div>
      <div>
        <input type="number" placeholder="Credit card number">
      </div>
      <input type="submit">
    </form>
  </body>
```
എന്നാൽ ഇത് Chrome-ൽ പ്രവർത്തിക്കില്ല. ഇത് JavaScript ഉപയോഗിച്ച് ഒഴിവാക്കിയിരിക്കുന്നു, പാചകക്കുറിപ്പിന്റെ ഒരു വകഭേദം കണ്ടെത്താനാകും ഇവിടെ.
X-Frame-Options തലക്കെട്ട് സൈറ്റ് കോഡിൽ സജ്ജീകരിച്ചിട്ടില്ല.
ഈ തലക്കെട്ട് ഫ്രെയിം, iframe, എംബഡ് അല്ലെങ്കിൽ ഒബ്ജക്റ്റ് ടാഗുകളെ ബാധിക്കുന്നു. അതിന്റെ സഹായത്തോടെ, ഒരു ഫ്രെയിമിനുള്ളിൽ നിങ്ങളുടെ സൈറ്റ് ഉൾപ്പെടുത്തുന്നത് നിങ്ങൾക്ക് പൂർണ്ണമായും നിരോധിക്കാം. ഇത് ചെയ്യുന്നതിന്, നിങ്ങൾ മൂല്യം വ്യക്തമാക്കേണ്ടതുണ്ട് X-Frame-Options: deny. അല്ലെങ്കിൽ നിങ്ങൾക്ക് X-Frame-Options വ്യക്തമാക്കാം: sameorigin, ഒരു iframe-ൽ ഉൾച്ചേർക്കുന്നത് നിങ്ങളുടെ ഡൊമെയ്‌നിൽ മാത്രമേ ലഭ്യമാകൂ.

എന്താണ് അപകടകരമായത്: അത്തരത്തിലുള്ള ഒരു തലക്കെട്ടിന്റെ അഭാവം ക്ഷുദ്ര സൈറ്റുകളിൽ ഉപയോഗിക്കാവുന്നതാണ് ക്ലിക്ക്ജാക്കിംഗ്. ഈ ആക്രമണത്തിനായി, ആക്രമണകാരി ബട്ടണുകൾക്ക് മുകളിൽ ഒരു സുതാര്യമായ ഫ്രെയിം സൃഷ്ടിക്കുകയും ഉപയോക്താവിനെ കബളിപ്പിക്കുകയും ചെയ്യുന്നു. ഉദാഹരണത്തിന്: തട്ടിപ്പുകാർ ഒരു വെബ്‌സൈറ്റിൽ സോഷ്യൽ നെറ്റ്‌വർക്കിംഗ് പേജുകൾ ഫ്രെയിം ചെയ്യുന്നു. ഈ സൈറ്റിലെ ഒരു ബട്ടണിൽ ക്ലിക്ക് ചെയ്യുകയാണെന്ന് ഉപയോക്താവ് കരുതുന്നു. പകരം, ക്ലിക്ക് തടസ്സപ്പെടുത്തുകയും ഉപയോക്താവിന്റെ അഭ്യർത്ഥന സജീവമായ സെഷൻ ഉള്ള സോഷ്യൽ നെറ്റ്‌വർക്കിലേക്ക് അയയ്ക്കുകയും ചെയ്യുന്നു. ഇങ്ങനെയാണ് ആക്രമണകാരികൾ ഉപയോക്താവിന് വേണ്ടി സ്പാം അയയ്ക്കുന്നത് അല്ലെങ്കിൽ വരിക്കാരും ലൈക്കുകളും നേടുന്നത്.

നിങ്ങൾ ഈ സവിശേഷത പ്രവർത്തനരഹിതമാക്കിയില്ലെങ്കിൽ, ഒരു ആക്രമണകാരിക്ക് നിങ്ങളുടെ ആപ്ലിക്കേഷൻ ബട്ടൺ ഒരു ക്ഷുദ്ര സൈറ്റിൽ സ്ഥാപിക്കാൻ കഴിയും. നിങ്ങളുടെ റഫറൽ പ്രോഗ്രാമിലോ നിങ്ങളുടെ ഉപയോക്താക്കളിലോ അയാൾക്ക് താൽപ്പര്യമുണ്ടാകാം.

ഒരു വെബ് ഡെവലപ്പർ ഓർമ്മിക്കേണ്ടത് എന്താണ്: വൈരുദ്ധ്യമുള്ള മൂല്യമുള്ള X-Frame-Options വെബ് സെർവറിലോ ലോഡ് ബാലൻസറിലോ സജ്ജമാക്കിയാൽ അപകടസാധ്യത സംഭവിക്കാം. ഈ സാഹചര്യത്തിൽ, സെർവറും ബാലൻസറും തലക്കെട്ട് മാറ്റിയെഴുതും, കാരണം ബാക്കെൻഡ് കോഡുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ അവർക്ക് ഉയർന്ന മുൻഗണനയുണ്ട്.

X-Frame-Options തലക്കെട്ടിന്റെ നിഷേധവും അതേ ഉത്ഭവ മൂല്യങ്ങളും Yandex വെബ് വ്യൂവറിന്റെ പ്രവർത്തനത്തെ തടസ്സപ്പെടുത്തും. വെബ് വ്യൂവർക്കായി iframes ഉപയോഗിക്കാൻ അനുവദിക്കുന്നതിന്, നിങ്ങൾ ക്രമീകരണങ്ങളിൽ ഒരു പ്രത്യേക നിയമം എഴുതേണ്ടതുണ്ട്. ഉദാഹരണത്തിന്, nginx-നായി നിങ്ങൾക്ക് ഇത് ഇതുപോലെ ക്രമീകരിക്കാം:
```
http{
...
 map $http_referer $frame_options {
 "~webvisor.com" "ALLOW-FROM http://webvisor.com";
 default "SAMEORIGIN";
 }
 add_header X-Frame-Options $frame_options;
...
}
```
PRSSI (പാത്ത്-റിലേറ്റീവ് സ്റ്റൈൽഷീറ്റ് ഇറക്കുമതി) കേടുപാടുകൾ.
ഇത് സൈറ്റിന്റെ സ്‌റ്റൈലിങ്ങിലെ ഒരു ദുർബലതയാണ്. സ്‌റ്റൈൽ ഫയലുകൾ ആക്‌സസ് ചെയ്യാൻ href="/ml/somefolder/styles.css/" പോലുള്ള ആപേക്ഷിക ലിങ്കുകൾ ഉപയോഗിക്കുകയാണെങ്കിൽ ഇത് സംഭവിക്കുന്നു. ഒരു ക്ഷുദ്ര പേജിലേക്ക് ഉപയോക്താവിനെ റീഡയറക്‌ടുചെയ്യാനുള്ള ഒരു മാർഗം കണ്ടെത്തിയാൽ ഒരു ആക്രമണകാരി ഇത് പ്രയോജനപ്പെടുത്തും. പേജ് അതിന്റെ url-ലേക്ക് ഒരു ആപേക്ഷിക ലിങ്ക് ചേർക്കുകയും ഒരു സ്റ്റൈൽ കോൾ അനുകരിക്കുകയും ചെയ്യും. നിങ്ങൾക്ക് badsite.ru/.../somefolder/styles.css/ പോലുള്ള ഒരു അഭ്യർത്ഥന ലഭിക്കും, അത് ഒരു ശൈലിയുടെ മറവിൽ ക്ഷുദ്രകരമായ പ്രവർത്തനങ്ങൾ ചെയ്യാൻ കഴിയും.

എന്താണ് അപകടകരമായത്: ഒരു വഞ്ചകൻ മറ്റൊരു സുരക്ഷാ ദ്വാരം കണ്ടെത്തിയാൽ ഈ അപകടസാധ്യത മുതലെടുത്തേക്കാം. തൽഫലമായി, കുക്കികളിൽ നിന്നോ ടോക്കണുകളിൽ നിന്നോ ഉപയോക്തൃ ഡാറ്റ മോഷ്ടിക്കാൻ കഴിയും.

ഒരു വെബ് ഡെവലപ്പർ ഓർമ്മിക്കേണ്ടത് എന്താണ്: X-Content-Type-Options തലക്കെട്ട് ഇതിലേക്ക് സജ്ജമാക്കുക: nosniff. ഈ സാഹചര്യത്തിൽ, ബ്രൗസർ ശൈലികൾക്കായുള്ള ഉള്ളടക്ക തരം പരിശോധിക്കും. ടെക്സ്റ്റ്/സിഎസ്എസ് അല്ലാത്ത തരമാണെങ്കിൽ, ബ്രൗസർ അഭ്യർത്ഥന തടയും.

ഗുരുതരമായ കേടുപാടുകൾ

ഒരു പാസ്‌വേഡ് ഫീൽഡ് ഉള്ള ഒരു പേജ് സെർവറിൽ നിന്ന് ഒരു സുരക്ഷിതമല്ലാത്ത ചാനലിലൂടെ കൈമാറ്റം ചെയ്യപ്പെടുന്നു (പാസ്‌വേഡ് ഫീൽഡ്(കൾ) അടങ്ങുന്ന HTML ഫോം HTTP വഴി നൽകുന്നു).
എൻക്രിപ്റ്റ് ചെയ്യാത്ത ചാനലിലൂടെ സെർവറിൽ നിന്നുള്ള പ്രതികരണം "മാൻ ഇൻ ദി മിഡിൽ" ആക്രമണത്തിന് ഇരയാകാം. സെർവറിൽ നിന്ന് ക്ലയന്റിലേക്ക് പേജ് സഞ്ചരിക്കുമ്പോൾ ഒരു ആക്രമണകാരിക്ക് ട്രാഫിക് തടസ്സപ്പെടുത്താനും ക്ലയന്റിനും സെർവറിനും ഇടയിൽ സ്വയം വെഡ്ജ് ചെയ്യാനും കഴിയും.

എന്താണ് അപകടകരമായത്: തട്ടിപ്പുകാരന് പേജ് മാറ്റിസ്ഥാപിക്കാനും ഉപയോക്താവിന് രഹസ്യാത്മക ഡാറ്റയ്ക്കായി ഒരു ഫോം അയയ്ക്കാനും കഴിയും, അത് ആക്രമണകാരിയുടെ സെർവറിലേക്ക് പോകും.

ഒരു വെബ് ഡെവലപ്പർ ഓർമ്മിക്കേണ്ടത് എന്താണ്: ചില സൈറ്റുകൾ ഉപയോക്താക്കൾക്ക് പാസ്‌വേഡിന് പകരം ഇമെയിൽ/ഫോൺ വഴി ഒറ്റത്തവണ കോഡ് അയയ്ക്കുന്നു. ഈ സാഹചര്യത്തിൽ, ദുർബലത അത്ര നിർണായകമല്ല, പക്ഷേ മെക്കാനിസം ഉപയോക്താക്കളുടെ ജീവിതത്തെ സങ്കീർണ്ണമാക്കും.
സുരക്ഷിതമല്ലാത്ത ഒരു ചാനലിലൂടെ ലോഗിൻ, പാസ്‌വേഡ് എന്നിവയുള്ള ഒരു ഫോം അയയ്‌ക്കുന്നു (ലോഗിൻ ഫോം HTTPS വഴി സമർപ്പിച്ചിട്ടില്ല).
ഈ സാഹചര്യത്തിൽ, ലോഗിൻ, പാസ്‌വേഡ് എന്നിവയുള്ള ഒരു ഫോം ഉപയോക്താവിൽ നിന്ന് എൻക്രിപ്റ്റ് ചെയ്യാത്ത ചാനൽ വഴി സെർവറിലേക്ക് അയയ്ക്കുന്നു.

എന്താണ് അപകടകരമായത്: മുമ്പത്തെ കേസിൽ നിന്ന് വ്യത്യസ്തമായി, ഇത് ഇതിനകം തന്നെ ഒരു നിർണായകമായ ദുർബലതയാണ്. സെൻസിറ്റീവ് ഡാറ്റ തടസ്സപ്പെടുത്തുന്നത് എളുപ്പമാണ്, കാരണം ഇത് ചെയ്യുന്നതിന് കോഡ് പോലും എഴുതേണ്ടതില്ല.
അറിയപ്പെടുന്ന കേടുപാടുകൾ ഉള്ള JavaScript ലൈബ്രറികൾ ഉപയോഗിക്കുന്നു.
സ്കാൻ സമയത്ത്, വിപുലമായ പതിപ്പുകളുള്ള jQuery ആയിരുന്നു ഏറ്റവും കൂടുതൽ ഉപയോഗിച്ച ലൈബ്രറി. ഓരോ പതിപ്പിനും കുറഞ്ഞത് ഒന്നോ അതിലധികമോ അറിയപ്പെടുന്ന കേടുപാടുകൾ ഉണ്ട്. ദുർബലതയുടെ സ്വഭാവത്തെ ആശ്രയിച്ച് ആഘാതം വളരെ വ്യത്യസ്തമായിരിക്കും.

എന്താണ് അപകടകരമായത്: അറിയപ്പെടുന്ന കേടുപാടുകൾക്കുള്ള ചൂഷണങ്ങളുണ്ട്, ഉദാഹരണത്തിന്:

ഒരു വെബ് ഡെവലപ്പർ ഓർമ്മിക്കേണ്ടത് എന്താണ്: പതിവായി സൈക്കിളിലേക്ക് മടങ്ങുക: അറിയപ്പെടുന്ന കേടുപാടുകൾക്കായി തിരയുക - പരിഹരിക്കുക - പരിശോധിക്കുക. നിങ്ങൾ ലെഗസി ലൈബ്രറികൾ മനഃപൂർവം ഉപയോഗിക്കുകയാണെങ്കിൽ, ഉദാഹരണത്തിന് പഴയ ബ്രൗസറുകൾ പിന്തുണയ്ക്കുന്നതിനോ പണം ലാഭിക്കുന്നതിനോ, അറിയപ്പെടുന്ന ഒരു അപകടസാധ്യത പരിഹരിക്കാനുള്ള അവസരത്തിനായി നോക്കുക.
ക്രോസ്-സൈറ്റ് സ്ക്രിപ്റ്റിംഗ് (XSS).
ക്രോസ്-സൈറ്റ് സ്ക്രിപ്റ്റിംഗ് (XSS), അല്ലെങ്കിൽ ക്രോസ്-സൈറ്റ് സ്ക്രിപ്റ്റിംഗ്, ഡാറ്റാബേസിൽ ക്ഷുദ്രവെയർ അവതരിപ്പിക്കുന്നതിന് കാരണമാകുന്ന ഒരു വെബ് ആപ്ലിക്കേഷന്റെ ആക്രമണമാണ്. Qualys അത്തരമൊരു അപകടസാധ്യത കണ്ടെത്തുകയാണെങ്കിൽ, ഒരു ആക്രമണകാരിക്ക് ക്ഷുദ്രകരമായ പ്രവർത്തനങ്ങൾ നടത്താൻ സൈറ്റ് കോഡിലേക്ക് സ്വന്തം js സ്ക്രിപ്റ്റ് അവതരിപ്പിക്കാൻ കഴിയും അല്ലെങ്കിൽ ഇതിനകം തന്നെ അവതരിപ്പിക്കാൻ കഴിയും എന്നാണ് ഇതിനർത്ഥം.

XSS സംഭരിച്ചു കൂടുതൽ അപകടകരമാണ്, കാരണം സ്ക്രിപ്റ്റ് സെർവറിൽ ഉൾച്ചേർക്കുകയും ബ്രൗസറിൽ ആക്രമിക്കപ്പെട്ട പേജ് തുറക്കുമ്പോഴെല്ലാം എക്സിക്യൂട്ട് ചെയ്യുകയും ചെയ്യുന്നു.

പ്രതിഫലിപ്പിക്കുന്ന XSS ഒരു ക്ഷുദ്ര സ്ക്രിപ്റ്റ് ഒരു എച്ച്ടിടിപി അഭ്യർത്ഥനയിലേക്ക് കുത്തിവയ്ക്കാൻ കഴിയുന്നതിനാൽ നടപ്പിലാക്കാൻ എളുപ്പമാണ്. അപ്ലിക്കേഷന് ഒരു HTTP അഭ്യർത്ഥന ലഭിക്കും, ഡാറ്റ സാധൂകരിക്കില്ല, അത് പാക്കേജുചെയ്‌ത് ഉടനടി അയയ്ക്കും. ഒരു ആക്രമണകാരി ട്രാഫിക്കിനെ തടസ്സപ്പെടുത്തുകയും ഒരു സ്ക്രിപ്റ്റ് ചേർക്കുകയും ചെയ്താൽ
```
<script>/*+что+то+плохое+*/</script> 
```
അപ്പോൾ ക്ലയന്റിന് വേണ്ടി ഒരു ക്ഷുദ്ര അഭ്യർത്ഥന അയയ്‌ക്കും.

XSS-ന്റെ ശ്രദ്ധേയമായ ഒരു ഉദാഹരണം: CVC, കാർഡ് കാലഹരണപ്പെടൽ തീയതി മുതലായവ നൽകുന്നതിനുള്ള പേജുകൾ അനുകരിക്കുന്ന js സ്നിഫറുകൾ.

ഒരു വെബ് ഡെവലപ്പർ ഓർമ്മിക്കേണ്ടത് എന്താണ്: Content-Security-Policy തലക്കെട്ടിൽ, ഒരു വിശ്വസനീയ ഉറവിടത്തിൽ നിന്ന് മാത്രം ഡൗൺലോഡ് ചെയ്ത് നടപ്പിലാക്കാൻ ക്ലയന്റ് ബ്രൗസറിനെ നിർബന്ധിക്കാൻ സ്ക്രിപ്റ്റ്-src ആട്രിബ്യൂട്ട് ഉപയോഗിക്കുക. ഉദാഹരണത്തിന്, script-src 'self' ഞങ്ങളുടെ സൈറ്റിൽ നിന്നുള്ള എല്ലാ സ്‌ക്രിപ്റ്റുകളും വൈറ്റ്‌ലിസ്റ്റ് ചെയ്യുന്നു.
ഇൻലൈൻ കോഡാണ് ഏറ്റവും മികച്ച രീതി: സുരക്ഷിതമല്ലാത്ത ഇൻലൈൻ മൂല്യം ഉപയോഗിച്ച് ഇൻലൈൻ ജാവാസ്ക്രിപ്റ്റ് മാത്രം അനുവദിക്കുക. ഈ മൂല്യം ഇൻലൈൻ js/css ഉപയോഗിക്കാൻ അനുവദിക്കുന്നു, എന്നാൽ js ഫയലുകൾ ഉൾപ്പെടുത്തുന്നത് നിരോധിക്കുന്നില്ല. script-src 'self'-യുമായി സംയോജിപ്പിച്ച് ഞങ്ങൾ എക്സിക്യൂട്ട് ചെയ്യുന്നതിൽ നിന്ന് ബാഹ്യ സ്ക്രിപ്റ്റുകൾ പ്രവർത്തനരഹിതമാക്കുന്നു.

റിപ്പോർട്ട്-ഉറി ഉപയോഗിച്ച് എല്ലാം ലോഗിൻ ചെയ്‌ത് സൈറ്റിൽ അത് നടപ്പിലാക്കാനുള്ള ശ്രമങ്ങൾ നോക്കുന്നത് ഉറപ്പാക്കുക.
SQL കുത്തിവയ്പ്പുകൾ.
വെബ്‌സൈറ്റിന്റെ ഡാറ്റാബേസ് നേരിട്ട് ആക്‌സസ് ചെയ്യുന്ന ഒരു വെബ്‌സൈറ്റിലേക്ക് SQL കോഡ് കുത്തിവയ്ക്കാനുള്ള സാധ്യതയെ ദുർബലത സൂചിപ്പിക്കുന്നു. ഉപയോക്താവിൽ നിന്നുള്ള ഡാറ്റ സ്‌ക്രീൻ ചെയ്‌തിട്ടില്ലെങ്കിൽ SQL കുത്തിവയ്‌പ്പ് സാധ്യമാണ്: അത് ശരിയാണോയെന്ന് പരിശോധിച്ചിട്ടില്ല, അത് അന്വേഷണത്തിൽ ഉടനടി ഉപയോഗിക്കും. ഉദാഹരണത്തിന്, ഒരു വെബ്‌സൈറ്റിലെ ഒരു ഫോം ഇൻപുട്ട് ഡാറ്റ തരവുമായി പൊരുത്തപ്പെടുന്നുണ്ടോയെന്ന് പരിശോധിക്കുന്നില്ലെങ്കിൽ ഇത് സംഭവിക്കുന്നു.

എന്താണ് അപകടകരമായത്: ഒരു ആക്രമണകാരി ഈ ഫോമിലേക്ക് ഒരു SQL അന്വേഷണം നൽകിയാൽ, അയാൾക്ക് ഡാറ്റാബേസ് ക്രാഷ് ചെയ്യാനോ രഹസ്യ വിവരങ്ങൾ വെളിപ്പെടുത്താനോ കഴിയും.

ഒരു വെബ് ഡെവലപ്പർ ഓർമ്മിക്കേണ്ടത് എന്താണ്: ബ്രൗസറിൽ നിന്ന് വരുന്ന കാര്യങ്ങൾ വിശ്വസിക്കരുത്. ക്ലയന്റ് ഭാഗത്തും സെർവർ ഭാഗത്തും നിങ്ങൾ സ്വയം പരിരക്ഷിക്കേണ്ടതുണ്ട്.

ക്ലയന്റ് ഭാഗത്ത്, JavaScript ഉപയോഗിച്ച് ഫീൽഡ് മൂല്യനിർണ്ണയം എഴുതുക.

ജനപ്രിയ ചട്ടക്കൂടുകളിലെ ബിൽറ്റ്-ഇൻ ഫംഗ്‌ഷനുകളും സെർവറിലെ സംശയാസ്പദമായ പ്രതീകങ്ങളിൽ നിന്ന് രക്ഷപ്പെടാൻ സഹായിക്കുന്നു. സെർവറിൽ പാരാമീറ്റർ ചെയ്ത ഡാറ്റാബേസ് അന്വേഷണങ്ങൾ ഉപയോഗിക്കാനും ശുപാർശ ചെയ്യുന്നു.

വെബ് ആപ്ലിക്കേഷനിൽ ഡാറ്റാബേസുമായുള്ള ഇടപെടൽ എവിടെയാണെന്ന് കൃത്യമായി നിർണ്ണയിക്കുക.

ഞങ്ങൾക്ക് എന്തെങ്കിലും വിവരം ലഭിക്കുമ്പോൾ ഇടപെടൽ സംഭവിക്കുന്നു: ഒരു ഐഡിയുള്ള ഒരു അഭ്യർത്ഥന (ഐഡിയുടെ മാറ്റം), ഒരു പുതിയ ഉപയോക്താവിനെ സൃഷ്ടിക്കൽ, ഒരു പുതിയ അഭിപ്രായം അല്ലെങ്കിൽ ഡാറ്റാബേസിലെ പുതിയ എൻട്രികൾ. ഇവിടെയാണ് SQL കുത്തിവയ്പ്പുകൾ സംഭവിക്കുന്നത്. ഞങ്ങൾ ഡാറ്റാബേസിൽ നിന്ന് ഒരു റെക്കോർഡ് ഇല്ലാതാക്കിയാലും, SQL കുത്തിവയ്പ്പ് സാധ്യമാണ്.

പൊതുവായ ശുപാർശകൾ

ചക്രം പുനർനിർമ്മിക്കരുത് - തെളിയിക്കപ്പെട്ട ചട്ടക്കൂടുകൾ ഉപയോഗിക്കുക. ചട്ടം പോലെ, ജനപ്രിയ ചട്ടക്കൂടുകൾ കൂടുതൽ സുരക്ഷിതമാണ്. .NET - ASP.NET MVC, ASP.NET Core എന്നിവയ്‌ക്കായി, പൈത്തണിന് - ജാങ്കോ അല്ലെങ്കിൽ ഫ്ലാസ്കിനായി, റൂബി - റൂബി ഓൺ റെയിൽസിന്, PHP - സിംഫണി, ലാറവെൽ, Yii, ജാവാസ്ക്രിപ്റ്റിന് - Node.JS-Express.js, ജാവയ്ക്ക് - സ്പ്രിംഗ് എംവിസി.

വെണ്ടർ അപ്‌ഡേറ്റുകൾ പിന്തുടരുക, പതിവായി അപ്‌ഡേറ്റ് ചെയ്യുക. അവർ ഒരു അപകടസാധ്യത കണ്ടെത്തും, തുടർന്ന് ഒരു ചൂഷണം എഴുതുകയും അത് പൊതുവായി ലഭ്യമാക്കുകയും ചെയ്യും, എല്ലാം വീണ്ടും സംഭവിക്കും. സോഫ്‌റ്റ്‌വെയർ വെണ്ടറിൽ നിന്നുള്ള സ്ഥിരമായ പതിപ്പുകളിലേക്കുള്ള അപ്‌ഡേറ്റുകൾ സബ്‌സ്‌ക്രൈബ് ചെയ്യുക.

ആക്സസ് അവകാശങ്ങൾ പരിശോധിക്കുക. സെർവർ വശത്ത്, നിങ്ങളുടെ സൈറ്റിനെ തകർക്കാൻ ആഗ്രഹിക്കുന്ന നിങ്ങളുടെ ഏറ്റവും വെറുക്കപ്പെട്ട ശത്രു എഴുതിയ ആദ്യത്തെ അക്ഷരം മുതൽ അവസാനത്തെ അക്ഷരം വരെ നിങ്ങളുടെ ഡാറ്റയുടെ സമഗ്രത ലംഘിക്കുന്നതുപോലെ എല്ലായ്പ്പോഴും നിങ്ങളുടെ കോഡ് കൈകാര്യം ചെയ്യുക. മാത്രമല്ല, ചിലപ്പോൾ ഇത് ശരിയാണ്.

ക്ലോണുകൾ, ടെസ്റ്റ് സൈറ്റുകൾ ഉപയോഗിക്കുക, തുടർന്ന് അവ ഉൽപ്പാദനത്തിനായി ഉപയോഗിക്കുക. ഇത് ആദ്യം, ഒരു ഉൽപാദന അന്തരീക്ഷത്തിൽ തെറ്റുകളും തെറ്റുകളും ഒഴിവാക്കാൻ സഹായിക്കും: ഉൽപ്പാദനപരമായ അന്തരീക്ഷം പണം കൊണ്ടുവരുന്നു, ലളിതമായ ഉൽപാദന അന്തരീക്ഷം നിർണായകമാണ്. ഏതെങ്കിലും പ്രശ്നം കൂട്ടിച്ചേർക്കുകയോ പരിഹരിക്കുകയോ അടയ്ക്കുകയോ ചെയ്യുമ്പോൾ, ഒരു ടെസ്റ്റ് പരിതസ്ഥിതിയിൽ പ്രവർത്തിക്കുന്നത് മൂല്യവത്താണ്, തുടർന്ന് കണ്ടെത്തിയ പ്രവർത്തനക്ഷമതയും കേടുപാടുകളും പരിശോധിക്കുക, തുടർന്ന് ഉൽപ്പാദന അന്തരീക്ഷത്തിൽ പ്രവർത്തിക്കാൻ ആസൂത്രണം ചെയ്യുക.

ഉപയോഗിച്ച് നിങ്ങളുടെ വെബ് ആപ്ലിക്കേഷൻ പരിരക്ഷിക്കുക വെബ് ആപ്ലിക്കേഷൻ ഫയർവാൾ അതോടൊപ്പം ദുർബലത സ്കാനറിൽ നിന്നുള്ള റിപ്പോർട്ടുകൾ സംയോജിപ്പിക്കുക. ഉദാഹരണത്തിന്, DataLine Qualys, FortiWeb എന്നിവ സേവനങ്ങളുടെ ഒരു ബണ്ടിൽ ഉപയോഗിക്കുന്നു.

അവലംബം: www.habr.com

മുൻനിര "നിർണ്ണായകമല്ലാത്ത" കേടുപാടുകൾ

ഗുരുതരമായ കേടുപാടുകൾ

പൊതുവായ ശുപാർശകൾ

ഒരു അഭിപ്രായം ചേർക്കുക മറുപടി റദ്ദാക്കാൻ

ഒരു അഭിപ്രായം ചേർക്കുക