Essas duas funções são um exagero para a higienização?

Para ser honesto, acho que o autor dessas funções não tem ideia do que são injeções de XSS e SQL ou o que exatamente a função usada faz.

Só para citar duas curiosidades:

Usando stripslashes depois de mysql_real_escape_string remove as barras que foram adicionadas por mysql_real_escape_string .
htmlentities substitui os personagens < e > que são usados em strip_tags para identificar tags.

Além disso:Em geral, as funções que protegem contra XSS não são adequadas para proteger contra injeções de SQL e vice-versa. Porque cada idioma e contexto tem seus próprios caracteres especiais que precisam ser cuidados.

Meu conselho é aprender por que e como a injeção de código é possível e como se proteger contra isso. Aprenda os idiomas com os quais está trabalhando, especialmente os caracteres especiais e como escapar deles.

Editar Aqui estão alguns exemplos (provavelmente estranhos):imagine que você permite que seus usuários insiram algum valor que deve ser usado como um segmento de caminho em um URI que você usa em algum código JavaScript em um onclick Valor do atributo. Portanto, o contexto da linguagem fica assim:

Valor do atributo HTML
- String JavaScript
  - Segmento de caminho de URI

E para torná-lo mais divertido:você está armazenando esse valor de entrada em um banco de dados.

Agora, para armazenar esse valor de entrada corretamente em seu banco de dados, você só precisa usar uma codificação adequada para o contexto em que está prestes a inserir esse valor em seu idioma de banco de dados (ou seja, SQL); o resto não importa (ainda). Como você deseja inseri-lo em uma declaração de string SQL, os caracteres especiais contextuais são os caracteres que permitem alterar esse contexto. Quanto às declarações de string, esses caracteres são (especialmente) o " , ' e \ caracteres que precisam ser escapados. Mas, como já foi dito, as declarações preparadas fazem todo o trabalho para você, então use-as.

Agora que você tem o valor em seu banco de dados, queremos produzi-lo corretamente. Aqui procedemos do contexto mais interno para o mais externo e aplicamos a codificação adequada em cada contexto:

Para o segmento de caminho de URI contexto, precisamos escapar (pelo menos) de todos os caracteres que nos permitem alterar esse contexto; neste caso / (sair do segmento de caminho atual), ? e # (ambos deixam o contexto do caminho do URI). Podemos usar rawurlencode para isso.
Para a string JavaScript contexto, precisamos cuidar de " , ' e \ . Podemos usar json_encode para isso (se disponível).
Para o valor do atributo HTML precisamos cuidar de & , " , ' e < . Podemos usar htmlspecialchars para isso.

Agora tudo junto:

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

Agora se $row['user-input'] é "bar/baz" a saída é:

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

Mas usar todas essas funções nesses contextos não é um exagero. Porque embora os contextos possam ter caracteres especiais semelhantes, eles têm sequências de escape diferentes. URI tem a chamada codificação percentual, JavaScript tem sequências de escape como \" e HTML tem referências de caracteres como " . E não usar apenas uma dessas funções permitirá quebrar o contexto.