Така че основно се зарових дълбоко в областите на MySQL и PHP... по-специално мерките за сигурност, които трябва да взема, когато се занимавам с базата данни и въвеждането на формуляри. Досега намирам следното за силно препоръчително:

Подготвени отчети
Използване на _real_escape_string()
НЕ използвайте магически кавички, тъй като обърква базите данни и в крайна сметка ви дава неща като „Вие не го нарекохте...“.

Всичко това е страхотно и го следя. Въпреки това се чудех дали знаци като знак за долар [$], знак за процент [%] и може би други трябва да бъдат екранирани. Може ли заявката да интерпретира знака за долар като PHP променлива, може би? Какво ще кажете за синтаксиса LIKE, за който съм чувал, че използва символа % или дори заместващ знак? Подготвените изявления трябва технически да се погрижат за всичко това, но аз просто исках да бъда на сигурно място и да се уверя, че съм отстранил всичко правилно. В случаите, когато забравя да използвам подготвени изявления или просто ги пренебрегвам, се надявах, че тази втора линия на защита може да ми каже, че мога да се отърва от световъртежа.

Ето какво използвам в момента за бягство:

Функция escape($connection, $data)( $new_data = trim($data); $new_data = i_real_escape_string($connection, $new_data); $new_data = addcslashes($new_data, "%_$"); $new_data = htmlspecialchars ($new_data, ENT_NOQUOTES); върне $new_data;

Така че това правилно ли е? Правя ли нещо ужасно грешно? Моля, имайте предвид, че при връщане на данните от базата данни ще трябва да ги изтрия задни плиткипреди символите $,% и _.

Правя ли нещо ужасно грешно?

Първо за вашите изследвания.

Подготвени отчети – единствениятчудесно нещо, което си намерил.

Въпреки че използването на mysqli_real_escape_string (ако приемем, че използвате подготвени изрази) би било безполезно и вредно(създаване на резултат, който сами сте отбелязали: „Извикахте isn\t...“).

А магическите цитати отдавна са премахнати от езика - следователно не струват нищо.

Така че дори повечето от първоначалните ви предпоставки са очевидно погрешни.

Сега към въпроса ви.

Възможно ли е заявката да е интерпретирала знака за долар като PHP променлива?

Какво ще кажете за синтаксиса LIKE, за който съм чувал, че използва символа % или дори заместващ знак?

Да, правилно чухте. Точната цел на оператора LIKE е да извърши търсене по модел. Деактивирането на тези символи в LIKE няма да има никакъв смисъл.

Всеки път, когато ще използвате оператора LIKE, трябва да решите кой конкретен знак да използвате и кой да забраните. Не може да се използва еднократно решение. Да не говорим, че във всички други взаимодействия с mysql знакът % няма специално значение.

Подготвените отчети трябва технически да се погрижат за всичко това

Подготвените отчети нямат нищо общо със знаците $ или %. Подготвените изрази се отнасят за SQL инжектиране, но нито един знак не може да го причини (не бихте могли да наречете „инжектиране“ правилно използван оператор LIKE, нали?).

И накрая, най-лошата част.

В случай, че забравите да използвате подготвени твърдения или просто пренебрегнете да ги следвате,

нищо няма да те спаси.

И най-малко помощ ще бъде от функцията, която сте разработили.

Обобщете.

Отървете се от тази функция.
Използвайте пълнители *за представяне на всяка отделна променлива в заявката.
Символите % и _ се избягват във входа само ако ще бъдат използвани в оператора LIKE и не искате да бъдат интерпретирани.
Използвайте htmlspecialchars() за изход, а не mysql вход.

*прочетете подготвените твърдения, ако този термин не ви е познат.

Не е нужно да избягвате знака за долар. MySQL не разглежда този символ конкретно и PHP го разпознава само в изходния код, не и в стойностите на низа (освен ако не извикате eval на низа, но това е съвсем друг червей от червеи).

Ще трябва да избегнете % и _ само ако сте използвали въвеждане от потребителя като аргумент LIKE и не искате потребителят да може да използва заместващи знаци. Това може да се случи, ако обработвате формуляр за търсене. Не е необходимо да го използвате, когато съхранявате в база данни.

Не е необходимо да използвате htmlspecialchars при достъп до базата данни. Това трябва да се използва само когато се показват данни на потребителя на HTML страницаза предотвратяване на XSS инжектиране.

В зависимост от това какви данни и за какво се използват.

Ако установите, че попълнените твърдения са PHP по подразбиранеса твърде големи и сложни, предлагам да разгледате някои от класовете, налични в github, за да ви дам представа за опростени заявки.

Пример за вмъкване на заявки с този клас

$data = масив ("login" => "admin", "active" => true, "firstName" => "John", "lastName" => "Doe", "password" => $db->func( "SHA1(?)", масив ("тайна парола+сол")), // парола = SHA1("тайна парола+сол") "createdAt" => $db->now(), // createdAt = NOW() " изтича" => $db->сега("+1Y") // изтича = СЕГА() + интервал 1 година // Поддържани интервали [s]секунда, [m]минута, [h]час, [d]ден, [M] месец, [Y] година); $id = $db->insert("потребители", $данни); if ($id) echo "потребител е създаден. Id=" . $id; else echo "неуспешно вмъкване: ". $db->getLastError();

Поради естеството на работата ми се налага да извършвам одити на сигурността изходен кодуеб приложения.
Много уеб приложения и много код...

Не е тайна, че уязвимостите при инжектиране на SQL са най-честите от всички уязвимости на уеб приложения от страна на сървъра. Има платформи и рамки, където подобни неща са почти напълно изключени, например ORM и така нататък, но статистиката упорито ни говори за абсолютния превес на уеб приложенията с прости конкатенирани SQL заявки. Освен това има случаи, при които ORM изобщо не може да се приложи. Например, когато не само параметрите на израза, но и самата логика на заявката на ниво оператор трябва да зависи от потребителските данни.

Така че нека започнем.

Безполезно бягство от герои

Намира се в 83% от PHP уеб приложенията, уязвими на SQL инжекции

Използване на функцията за изход за знаци като
mysql_escape_string
mysql_real_escape_string
добавя наклонени черти
без кавички. Най-често се проявява в числови параметри (всички видове *_id).

Пример

$sql = "ИЗБЕРЕТЕ потребител ОТ потребителски списък WHERE userid=".mysql_real_escape_string($_GET["uid"]);

На външен вид това защитен код, но само на външен вид. Най-често срещаният модел на SQL инжекции в PHP в моята практика се промъкна тук. За да атакува тази уязвимост, атакуващият просто трябва да избягва използването на символите " " \x00 \r \n \x1a във вектора на атаката.
Например:
/index.php?uid=-777 UNION SELECT парола FROM потребителски списък

Търсене в код

Логиката на израза за търсене е следната: намерете всички редове, в които няма последователност от кавички ("", "", "", "") вляво от филтриращите функции. Методът, разбира се, далеч не е 100%, но е невъзможно да се изисква регулярен израз за извършване на семантичен анализ.
За да улесните показването на информация, можете да маркирате функцията в цвят в конзолата:
egrep -Rin "(изберете|актуализирайте|вмъкнете|изтрийте|заменете).*(от|настройте|в).*(mysql_escape_string|mysql_real_escape_string|добавя наклонени черти)" . | grep -v "[\""]["\"]" | egrep --color "(mysql_escape_string|mysql_real_escape_string|добавя наклонени черти)"

За да се предпазите от тази уязвимост със заместващ знак, най-добре е да използвате преобразуване на типове.
Това винаги работи по-бързо и е по-надеждно от всички видове филтриране и скрининг.
За примера по-горе корекцията може да бъде така:
$sql = "ИЗБЕРЕТЕ потребител ОТ потребителски списък WHERE userid=".intval($_GET["uid"]);

Това завършва краткото есе. Призовавам всички уеб разработчици да се опитат да проверят източниците си за такива проекти. Още по-добре, разширете дадения скрипт за търсене на хора.

Първо, малко за това защо са необходими тези наклонени черти като цяло.
Ако заместим някакви данни в заявката, тогава, за да разграничим тези данни от SQL командите, те трябва да бъдат поставени в кавички.
Например, ако пишете
SELECT * FROM таблица WHERE име = Бил
тогава базата данни ще реши, че Bill е името на друго поле, няма да го намери и ще изведе грешка. Следователно заместените данни (в този случай името Bill) трябва да бъдат затворени в кавички - тогава базата данни ще ги счита за низ, чиято стойност трябва да бъде присвоена на полето за име:
SELECT * FROM таблица WHERE име = "Бил"
Кавичките обаче може да се появят и в самите данни. например,
SELECT * FROM таблица WHERE име = "D"Artagnan"
Тук базата данни ще реши, че "D" е данни, а Artagnan е команда, която не знае, и също ще изведе грешка. Следователно е необходимо да се проследят всички данни, за да се обясни на базата данни, че кавичките (и някои други специални знаци), намерени в тях, се отнасят за данните.
В резултат на това ще получим правилна заявка, която няма да причини грешки:
SELECT * FROM table WHERE name = "D\"Artagnan"

Така открихме, че когато заместваме низови данни в заявка, трябва да се следват две правила:
- всички въведени низови данни трябва да бъдат затворени в кавички (единични или двойни, но единичните са по-удобни и по-често използвани).
- специалните знаци трябва да бъдат екранирани с наклонени черти.

Трябва да се отбележи специално: добавените наклонени черти НЕ влизат в базата данни. Те са необходими само в заявката. При удар в основата наклонените черти се изхвърлят. Съответно, често срещана грешка е използването на наклонени черти при извличане на данни от базата данни.

Всичко по-горе се отнася за низови данни и дати. Числата могат да се вмъкват, без да ги завършват или ограждат с кавички. Ако направите това тогава ЗАДЪЛЖИТЕЛНО!принудете данните към желания тип, преди да ги вмъкнете в заявката, например:
$id = intval ($id);
Въпреки това, за простота (и надеждност), можете да работите с числа като с низове (тъй като mysql все още ги преобразува в желания тип). Съответно ще проследим всички данни, въведени в заявката, и ще ги поставим в кавички.

Освен това има още едно правило - незадължително, но трябва да се спазва, за да избегнете грешки:
Имената на полетата и таблиците трябва да бъдат оградени в единични кавички - "`" (клавишът с този символ се намира на стандартната клавиатура вляво от клавиша "1"). В крайна сметка името на полето може да съвпада с ключови думи mysql, но ако използваме обратен цитат, тогава MySQL ще разбере всичко правилно:
SELECT * FROM `table` WHERE `date` = "2006-04-04"
Трябва да правите разлика между тези кавички и да не ги бъркате. Трябва също да запомните, че обратните отметки не се избягват от наклонени черти.

И така, ние се научихме как правилно да заместваме данни в заявка.
НО! Динамичната конструкция на заявка не се ограничава до заместване на данни. Често трябва да заместваме SQL команди и имена на полета в заявка. И тук преминаваме към темата за сигурността:

SQL Injection е правилният начин хакерска атака, когато данните, предадени на скрипта, се модифицират по такъв начин, че заявката, генерирана в този скрипт, започва да прави нещо напълно различно от това, за което е предназначена.
Правилата за защита срещу такива атаки могат да бъдат разделени на две точки:
1. Работа с данни.
2. Работа с контроли за заявки.

Обсъдихме подробно първата точка по-горе. Може да се каже, че всъщност не е защита. Спазването на правилата за добавяне на данни към заявка е продиктувано преди всичко от изискванията на SQL SYNTAX. А като страничен ефект имаме и защита срещу хакване.

Втората точка е много по-трудна, тъй като няма едно универсално правило за данните - обратните тикове няма да предпазят името на полето от промяна от хакер. Не е възможно да защитите име на таблица с кавички. SQL изрази, параметри на командата LIMIT и други оператори.
Следователно основното правило при заместване на контролни елементи в заявка е:
Ако трябва динамично да вмъкнете SQL изрази или имена на полета, бази данни, таблици в заявка, тогава при никакви обстоятелства не трябва да ги вмъквате директно в заявката.
Всички опции за такива добавки трябва да бъдат написани ПРЕДВАРИТЕЛНО във вашия скрипт и избрани въз основа на въведеното от потребителя.
Например, ако трябва да предадете име на поле към поръчката по оператор, тогава при никакви обстоятелства не трябва да го замествате директно. Първо трябва да го проверим. Например, направете масив от валидни стойности и го заменете в заявката само ако предаваният параметър присъства в този масив:
$orders =масив("име" , "цена" , "количество" );
$key = array_search($_GET["sort"], $orders));
$orderby = $orders [ $key ];
$заявка = "ИЗБЕРЕТЕ * ОТ `таблица` ПОРЪЧАЙТЕ ПО$orderby ";

Търсим въведената от потребителя дума в масива от предварително описани опции и ако я намерим, избираме съответния елемент от масива. Ако не бъде намерено съвпадение, ще бъде избран първият елемент от масива.
По този начин това, което се замества в заявката, не е това, което потребителят е въвел, а това, което е написано в нашия скрипт.
Същото трябва да се направи и във всички останали случаи.
Например, ако клаузата WHERE се генерира динамично:
if (!empty($_GET [ "price" ])) $where .= "price="" . mysql_real_escape_string ($_GET [ "price" ]). """ ;
$query = "SELECT * FROM `table` WHERE $where " ;

Трудно ми е да си представя случай, в който име на таблица може да бъде вмъкнато в заявка динамично, но ако това се случи, тогава името също трябва да бъде вмъкнато само от набор, предварително дефиниран в скрипта.
Параметрите на оператора LIMIT трябва да бъдат принудени да бъдат целочислен тип с помощта на аритметични операции или функцията intval().
Не мислете, че изброените тук примери изчерпват всички възможности за конструиране на динамична заявка. Просто трябва да разберете принципа и да го прилагате във всички подобни случаи.

(PHP 4 >= 4.3.0, PHP 5)

mysql_real_escape_string — Премахва специални знаци в низ за използване в SQL оператор

Описание

mysql_real_escape_string (низ $unescaped_string [, ресурс $link_identifier = NULL]): низ

Екранира специални знаци в unescaped_string, като взема предвид текущия набор от знаци на връзката, така че да е безопасно да го поставите в mysql_query(). Ако трябва да се вмъкнат двоични данни, трябва да се използва тази функция.

mysql_real_escape_string() извиква библиотечната функция на MySQL mysql_real_escape_string, която добавя обратни наклонени черти към следните знаци: \x00, \n, \r, \ , " , " и \x1a.

Тази функция трябва винаги (с малки изключения) да се използва, за да защити данните, преди да изпрати заявка до MySQL.

Внимание

Сигурност: наборът от символи по подразбиране

Наборът от символи трябва да бъде зададен или на ниво сървър, или с функцията API mysql_set_charset()за да повлияе mysql_real_escape_string() . Вижте раздела с концепции за набори от знаци за повече информация.

Параметри

неекраниран_низ

Низът, който трябва да бъде екраниран.

Идентификатор_връзка

MySQL връзката. Ако идентификаторът на връзката не е посочен, последната връзка, отворена от mysql_connect()се предполага. Ако не бъде намерена такава връзка, ще се опита да създаде такава, сякаш mysql_connect()беше призован без аргументи. Ако не бъде намерена или установена връзка, an E_ПРЕДУПРЕЖДЕНИЕсе генерира грешка в нивото.

Върнати стойности

Връща екранирания низ, или НЕВЯРНОпри грешка.

Грешки/Изключения

Изпълнението на тази функция без налична MySQL връзка също ще издаде E_ПРЕДУПРЕЖДЕНИЕниво PHP грешки. Изпълнявайте тази функция само с налична валидна MySQL връзка.

Примери

Пример #1 Прост mysql_real_escape_string() пример

//Свързване
$link = mysql_connect("mysql_host", "mysql_user", "mysql_password")
ИЛИ die(mysql_error());

//Запитване
$query = sprintf ( "ИЗБЕРЕТЕ * ОТ потребители WHERE потребител = "%s" И парола = "%s"",
mysql_real_escape_string($user),
mysql_real_escape_string($парола));
?>

Пример #2 mysql_real_escape_string() изисква пример за свързване

Този пример демонстрира какво се случва, ако няма MySQL връзка при извикване на тази функция.

Горният пример ще изведе нещо подобно на:

Предупреждение: mysql_real_escape_string(): Няма такъв файл или директория в /this/test/script.php на ред 5 Предупреждение: mysql_real_escape_string(): Не може да бъде установена връзка към сървъра в /this/test/script.php на ред 5 bool(false) string(41) "SELECT * FROM актьори WHERE last_name = """

Пример #3 Примерна атака с инжектиране на SQL

// Не проверихме $_POST["парола"], може да е всичко, което потребителят иска, например:
$_POST [ "username" ] = "aidan" ;
$_POST [ "парола" ] = "" ИЛИ ""="" ;

// Заявка към база данни, за да провери дали има съвпадащи потребители
$query = ( $_POST [ "потребителско име" ]) " И парола=" ( $_POST [ "парола" ]) "" ;
mysql_query($query);

// Това означава, че заявката, изпратена до MySQL, ще бъде:
ехо $заявка;
?>

Заявката, изпратена до MySQL:

Това ще позволи на всеки да влезе без валидна парола.

Бележки

Преди употреба е необходима връзка с MySQL mysql_real_escape_string() в противен случай грешка на ниво E_ПРЕДУПРЕЖДЕНИЕсе генерира и НЕВЯРНОсе връща. Ако link_identifier не е дефиниран, използва се последната MySQL връзка.

Забележка: mysql_real_escape_string() не избяга % и _ . Това са заместващи символи в MySQL, ако се комбинират с ХАРЕСАЙТЕ, ГРАНТ, или ОТМЕНЯ.

преди 8 години

Само малка функция, която имитира оригиналния mysql_real_escape_string, но която не се нуждае от активна mysql връзка, може да бъде внедрена като статична функция в клас база данни.

функция mysql_escape_mimic ($inp) (
if(is_array($inp))
връща array_map (__METHOD__, $inp);

If(!empty($inp) && is_string ($inp)) (
return str_replace (array("\\" , "\0" , "\n" , "\r" , """ , """ , "\x1a") , array("\\\\", "\ \0" , "\\n" , "\\r" , "\\"" , "\\"", "\\Z") ), $inp );
}

Връщане $inp;
}
?>

преди 13 години

Обърнете внимание, че mysql_real_escape_string не добавя обратни наклонени черти към \x00, \n, \r и и \x1a, както е споменато в документацията, но всъщност замества знака с приемливо представяне на MySQL за заявки (напр. \n се заменя с "\ n" буква). (\, " и " са екранирани, както е документирано) Това не променя начина, по който трябва да използвате тази функция, но мисля, че е добре да знаете.

преди 6 години

Нито едно обсъждане на бягството не е пълно, без да се каже на всички, че по принцип никога не трябва да използвате външен вход за генериране на интерпретиран код. Това важи за SQL изрази или нещо, което бихте нарекли някаква функция "eval".

Така че, вместо да използвате тази ужасно повредена функция, вместо това използвайте параметрични подготвени изрази.

Честно казано, използването на предоставени от потребителя данни за съставяне на SQL изрази трябва да се счита за професионална небрежност и трябва да бъдете държани отговорни от вашия работодател или клиент, ако не използвате подготвени параметрични изрази.

какво значи това

Това означава, че вместо изграждане на SQL израз като този:

"INSERT INTO X (A) VALUES(".$_POST["a"].)"

Трябва да използвате функцията () на mysqli, за да изпълните оператор, който изглежда така:

"ВМЪКНЕТЕ В X (A) СТОЙНОСТИ(?)"

NB: Това не означава, че никога не трябва да генерирате динамични SQL изрази. Това означава, че никога не трябва да използвате данни, предоставени от потребителя, за да генерирате тези изрази. Всички предоставени от потребителя данни трябва да бъдат предадени като параметри на израза, след като са е подготвен.

Така че, например, ако изграждате малка рамка и искате да направите вмъкване към таблица въз основа на URI на заявката, във ваш интерес е да не приемате стойността $_SERVER["REQUEST_URI"] (или която и да е част от него) и директно да го свържете с вашата заявка. Вместо това трябва да анализирате частта от стойността $_SERVER["REQUEST_URI"], която искате, и да я картографирате чрез някакъв вид функция или асоциативен масив към непотребител. Ако преобразуването не дава стойност, вие знаете, че нещо не е наред с предоставените от потребителя данни.

Неспазването на това е причината за редица проблеми с SQL инжектиране в рамката на Ruby On Rails, въпреки че използва параметрични подготвени изрази. Ето как GitHub беше хакнат в един момент. Така че нито един език не е имунизиран срещу този проблем. Ето защо това е обща най-добра практика, а не нещо специфично за PHP и защо НАИСТИНА трябва да го приемете.

Освен това все още трябва да правите някакъв вид валидиране на данните, предоставени от потребителите, дори когато използвате параметрични подготвени изрази. Това е така, защото тези предоставени от потребителя данни често стават част от някакъв генериран HTML и искате да сте сигурни, че предоставените от потребителя данни няма да причинят проблеми със сигурността в браузъра.

преди 9 години

В пример #2 има интересна странност за SQL инжектиране: И има приоритет пред ИЛИ, така че инжектираната заявка всъщност се изпълнява като WHERE (user="aidan" И парола="") ИЛИ ""="", така че вместо това за връщане на запис в базата данни, съответстващ на произволно потребителско име (в този случай "aidan"), това всъщност ще върне ВСИЧКИ записи в базата данни без определен ред, така че атакуващият може да влезе като който и да е акаунт .контрол кой е акаунтът.

Разбира се, потенциалният потенциал за атака може просто да промени параметрите си, за да насочи конкретни потребители, представляващи интерес:

//Напр. ценностите на нападателя
$_POST [ "username" ] = "" ;
$_POST["парола"] = "" ИЛИ потребител = "администратор" И "" = "";

// Неправилно формирана заявка
$заявка = "ИЗБЕРЕТЕ * ОТ потребители WHERE потребител ="$_POST [ потребителско име ] " И парола = " $_POST [ парола ] "" ;

ехо $заявка;

// Заявката, изпратена до MySQL, ще гласи:
// ИЗБЕРЕТЕ * ОТ потребители WHERE user="" AND password="" OR user="administrator" AND ""="";
// което би позволило на всеки да получи достъп до акаунта с име "администратор"

преди 1 година

@feedr
Разработих бележката му по следния начин:
$string = "asda\0sd\x1aas\\\\\\\\dasd\"asdasd\na\"\"sdasdad";
$масив1 = масив("\\\\\\\\", "\0", "\n", "\r", """, """, "\x1a");
$масив2 = масив("\\\\\\\\\\\\\\\\\", "\\\0", "\\\n", "\\\r", "\\\ " ", "\\\"", "\\\Z");
ехо ($ низ);
ехо (PHP_EOL);
за ($i=0; $i ако ($i==0)
$p = "/(?друго
$p = "/(?ехо ($i);
ехо ($p);
ехо ($масив2[$i]);
$string = preg_replace($p, $array2[$i], $string);
ехо("\t");
ехо ($ низ);
ехо (PHP_EOL);
}
ехо (PHP_EOL);
ехо ($ низ);

преди 2 години

Да цитирам Сам в Numb Safari

[ „Никоя дискусия за бягството не е пълна, без да се каже на всички, че по принцип никога не трябва да използвате външен вход за генериране на интерпретиран код. Това важи за SQL изрази или нещо, което бихте нарекли всякакъв вид функция „eval“.

Сам е прав.........

Въпреки това не мисля, че е разумно да спрем всички дезинфекция и просто да прехвърлим задачата на параметрични подготвени изрази.

Конкретен разработчик, работещ в конкретна ситуация, винаги ще знае повече за валидния вход (специфичен за този контекст).

Ако помолите потребител да предаде стойност, която вече сте му дали и знаете, че всички такива стойности започват с AB****** и низът трябва да е с дължина 7 или 11, но никога друга дължина, тогава имате основата на добър преддезинфектант - различните допустими дължини на низ може да показват наследени данни.

Никога не бих искал просто да предавам боклука, който злонамерен потребител може да е предал през формуляр към параметричните подготвени отчети, винаги бих искал първо да направя моите собствени проверки за здравословност и в някои случаи те може да са от страна на предпазливост и просто изберете да прекратите напълно операцията на базата данни.

По този начин моята база данни не се запушва с опасни изявления, направени безопасни - тя просто не се запушва, което е по-добре.

Сигурност в слоеве - санирането и валидирането все още трябва да се вземат предвид във всяка ситуация ПРЕДИ да се използват подготвени отчети.

Освен това, доколкото мога да прочета в официалния документ
==============================================

„Бягство и SQL инжектиране

Обвързаните променливи се изпращат до сървъра отделно от заявката и по този начин не могат да й пречат. Сървърът използва тези стойности директно в точката на изпълнение, след като шаблонът на израза бъде анализиран. Обвързаните параметри не трябва да бъдат екранирани, тъй като никога не се заместват директно в низа на заявката"

Това ми подсказва, че опасността се избягва във вътрешните органи чрез алтернативно боравене, а не чрез анулиране.

Това означава, че голям проект с непълно преобразуване в подготвени изявления, наследен код в различни части на организация или сървъри, които си говорят помежду си, могат да предадат лошите новини от имунизирано място или ситуация на такова, което не е имунизирано.

Докато дезинфекцията се извършва компетентно, без да поема допълнителни рискове, тогава лично аз бих се придържал към определени слоеве на дезинфекция и след това бих се обадил на подготвените отчети.

Как се работи