Recherche avancée

Sur d’autres sites (8505)

• Anomalie #3917 (Rejeté) : Faille de sécurité potentielle

  4 mars 2017, par Jean Trébuchet

  Il y a une grosse faille de sécurité potentielle, pas directement liée au code de Spip mais à son utilisation.

  Il se trouve que les codes php "< ?php ... ?>" contenus non seulement dans les squelettes mais aussi dans les balises et les filtres sont exécutés lors du calcul de la page.
  Or cela ouvre la porte à des attaques si le webmaster n’en est pas conscient...

  Par exemple dans ce bout de code j’affiche un input dont l’attribut "value" est correspond à la valeur envoyée par l’internaute en $_GET :
  (#REM" />

  Je fais cette opération via un filtre recherche_get{recherche} qui récupère la valeur à affichée, comme cela ne concerne que de l'affichage je n'ai pas pris la peine de bien la nettoyer. ... Et du coup l'internaute malveillant aurait pu exécuter n'importe quel code php en l'injectant dans la requête !

  Bon j’avoue dans l’absolu c’est pas très malin de ne pas nettoyer une variable... Mais ne serait-il pas prudent d’interdire de base l’exécution de code php dans les squelettes (ou au moins dans les balises + filtres) quitte à laisser la possibilité à ceux qui le veulent de lever cette interdiction via la config ?

• Anomalie #3263 (Nouveau) : Vignettes des moteurs de recherche en panne

  8 septembre 2014, par Franck Dalot

  Bonjour :-)
  SPIP 3.0.17 [21515]
  php 5.4.30
  Base de données en MySQL
  Firefox 32

  Quand je regarde dans les statistiques les "Liens entrants", les vignettes des moteurs de recherche ne fonctionnent pas.
  Quand je regarde avec Firebug, il semble que le lien ne soit pas bon. Exemple concernant Google
  Cela m’affiche :
  http://www.apercite.fr/api/apercite/120x90/oui/oui/http://Google
  Alors que cela devrait plutôt être :
  http://www.apercite.fr/api/apercite/120x90/oui/oui/http://Google.fr
  voir peut-être même :
  http://www.apercite.fr/api/apercite/120x90/oui/oui/https://Google.fr
  Cela ne devrait pas afficher les www ?

  Un autre exemple qui me fait penser que le problème vient peut-être de :
  http://zone.spip.org/trac/spip-zone/browser/_core_/branches/spip-3.0/plugins/statistiques/engines-list.txt

  Dans le cas de AOL France
  Il y a recherche de la vignette à :
  http://www.apercite.fr/api/apercite/120x90/oui/oui/http://AOL%20France
  et non à :
  http://www.apercite.fr/api/apercite/120x90/oui/oui/http://aol.fr
  Franck

• Révision 23364 : Restructuration complète du critère `{par xxx}` pour y voir plus clair et apporte...

  31 janvier 2017, par marcimat@rezo.net

  - les expressions telles que `par num titre` ou `par multi titre` sont extensibles. `par expr champ` cherchera une fonction
  `calculer_critere_par_expression_expr` pour gérer cette expression

  - une fonction `calculer_critere_par_champ()` est utilisée pour retrouver la table de tri d’un champ demandé.
  Cette fonction est d’ailleurs aussi utilisée par les fonctions `num` ou `multi`.
  Cela harmonise un peu les diverses utilisations entre ces 3 cas principaux `par xpar num xpar multi x`.

  x peut être :
  - un champ de la table (titre),
  - un champ dont la table de jointure est nommé (documents.titre),
  - un champ dont l’alias de table est nommé (L1.titre) (à éviter, surtout là pour compat)
  - un champ d’exception de jointure (titre_mot)
  - un champ d’une autre table dont la jointure est explicite (ARTICLES documents)par taille
  - un champ d’une autre table dont la jointure est possible (DOCUMENTS)par rang_lien

  Le changement est que si la jointure existe déjà pour un champ, le champ sera correctement préfixé de l’alias de table correspondant,
  et dans certains cas une nouvelle jointure ne sera pas créé inutilement.

  Entre autres :
  - `(DOCUMENTS)id_article ?id_rubrique ?vu=nonpar rang_lien`, le ORDER BY de rang_lien est bien préfixé de l’alias d’une table de jointure.
  Il ne peut plus y avoir d’ambiguité sur le champ, rapporté par Mysql si la table de jointure est présente 2 fois. Cependant le ticket #3894 reste entier.