Тези две функции излишни ли са за дезинфекция?

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

Само да назовем две странности:

• Използване на stripslashes след mysql_real_escape_string премахва наклонените черти, добавени от mysql_real_escape_string .
• htmlentities замества чатактите < и > които се използват в strip_tags за да идентифицирате тагове.

Освен това:Като цяло функциите, които защитават срещу XSS, не са подходящи за защита срещу SQL инжекции и обратно. Защото всеки език и контекст имат свои специални знаци, за които трябва да се погрижим.

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

Редактиране Ето един (вероятно странен) пример:Представете си, че позволявате на потребителите си да въвеждат някаква стойност, която трябва да се използва като сегмент на пътя в URI, който използвате в някакъв JavaScript код в onclick стойност на атрибута. Така езиковият контекст изглежда така:

• Стойност на HTML атрибута
  • JavaScript низ
    • Сегмент на пътя на URI

И за да стане по-забавно:Вие съхранявате тази входна стойност в база данни.

Сега, за да съхраните правилно тази входна стойност във вашата база данни, просто трябва да използвате подходящо кодиране за контекста, в който ще вмъкнете тази стойност в езика на вашата база данни (т.е. SQL); останалото няма значение (все още). Тъй като искате да го вмъкнете в декларация на SQL низ, контекстуалните специални символи са знаците, които ви позволяват да промените този контекст. Що се отнася до декларациите на низове, тези знаци са (особено) " , ' и \ знаци, които трябва да бъдат екранирани. Но както вече беше посочено, подготвените изявления вършат всичко това вместо вас, така че ги използвайте.

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

• За сегмента на пътя на URI контекст, от който се нуждаем, за да избягаме (поне) от всички онези знаци, които ни позволяват да променим този контекст; в този случай / (напускане на текущия сегмент на пътя), ? и # (и двете оставят контекста на пътя на URI). Можем да използваме rawurlencode за това.
• За низът на JavaScript контекст, който трябва да се погрижим за " , ' и \ . Можем да използваме json_encode за това (ако има такива).
• За стойността на HTML атрибута трябва да се погрижим за & , " , ' и < . Можем да използваме htmlspecialchars за това.

Сега всичко заедно:

'… onclick="'.htmlspecialchars('window.open("http://example.com/'.json_encode(rawurlencode($row['user-input'])).'")').'" …'

Сега ако $row['user-input'] е "bar/baz" изходът е:

… onclick="window.open("http://example.com/"%22bar%2Fbaz%22"")" …

Но използването на всички тези функции в тези контексти не е излишно. Тъй като въпреки че контекстите могат да имат подобни специални символи, те имат различни escape последователности. URI има така нареченото процентно кодиране, JavaScript има escape последователности като \" и HTML има препратки към знаци като " . И неизползването само на една от тези функции ще позволи да се прекъсне контекста.