Modification de la couleur de mes en-têtes de courses.

[ortolojf]

Bonjour

Récemment, j'ai changé le background de mes en-têtes de courses vers du gris alternant avec du bleu :

https://www.pronostics-courses.fr/php/courses-lendemain/pronostics-courses-1-1.html

Celà ne me semble pas très ergonomique.

Pourriez-vous me conseiller pour d'autres couleurs claires ?

Merci beaucoup.

 

[spout]

 

[ortolojf]

Bon bon...

J'y ai mis du background-color: rgb(245, 250, 255, 0.7);

Merci spout.

 

[rick38]

C'est une révolution !

 

[spout]

Moi je trouve que c'est plus sexy en rose :
https://t.ly/YNNER

 

[rick38]

Avec un petit message pour bien annoncer le grand changement :
https://t.ly/vFbnz

Voilà on a amélioré son site.

 

[ortolojf]

Bonjour rick38

A part Javascript et les feuilles de style, quel risque pour mon site ?

Et, comment empêcher ce hack ?

Merci beaucoup.

 

[ortolojf]

Ah.

Je vais voir.

https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Vous préconisez htmlentities(), htmlspecialchars() ou strip_tags() ?

Merci beaucoup.

 

[spout]

htmlspecialchars()

 

[ortolojf]

Bonjour spout

htmlspecialchars() ne traduit que des tags html très limités, et htmlentities() les traduit entièrement.

strip_tags les supprime tout simplement.

Y a-t-il un inconvénient pour htmlentities() ?

A part çà, filtrer les données des get/post etc...

Et empêcher l'infiltration de scripts intrusifs.

Merci beaucoup.

 

[spout]

Il faut juste "échapper" les <, >, ", etc ... pas d'intérêt les autres entités.

 

[ortolojf]

Merci beaucoup spout

Dans quels contextes on doit filtrer avec htmlspecialchars() ?

Les paramètres GET et POST, ( filtrage, éventuellement bannissement si abusif ),

Les affichages du textarea de ma form de contact, ( possibilité d'injection de script ),

Quoi d'autre ?

 

[ortolojf]

Et puis...

Comment se protéger contre l'injection dans un textarea d'un script ( ou iframe ), urlencodé ?

Et tout contenu urlencodé.

On peut le décoder, mais celà permet-il de prévoir tous les cas ?

Merci beaucoup.

 

[spout]

Absolument tout ce qui est affiché doit passer dans htmlspecialchars(), mais par contre tu dois enregistrer tel quel en base de données (sans échapper).
Les frameworks font tous ça dans leurs templates :
Laravel : Blade : {{ $var }}
CakePHP : <?php echo h($var); ?>
Symfony : Twig : {{ var }}
Django : {{ var }}
VueJS : {{ var }}

 

[ortolojf]

Ah, bon...

Et le contenu urlencodé ?

Il n'est pas sensible directement à htmlspecialchars().

On décode et on traite ?

Ou c 'est automatique à la lecture des post get...

Celà m'étonne qu'il n'y ait pas besoin de filtrer/valider les entrées.

 

[spout]

Les entrées il faut juste les échapper pr éviter les injections SQL.

 

[ortolojf]

Bon je vais arranger mon site.

Merci beaucoup spout.

 

[ortolojf]

Bof...

https://www.pronostics-courses.fr

J'ai arrangé quelques filtrages de _GET.

Théoriquement les _POST de la page d'accueil doivent être filtrés.

A part çà, spout, les pages html elles-même ne doivent pas passer à la moulinette de htmlspecialchars(), sinon elles ne seraient pas interprétées par le browser ?

Merci de tester mon site.

Amicalement.

 

[spout]

Pas les pages, juste où tu affiches tes variables :

<?php echo htmlspecialchars($_GET['foo']); ?>
<?php echo htmlspecialchars($foo); ?>
<ul>
<?php foreach($records as $record): ?>
    <li><?php echo htmlspecialchars($record['title']); ?></li>
<?php endforeach; ?>
</ul>
<input type="text" name="foo" value="<?php echo htmlspecialchars($_POST['foo'] ?? ''); ?>">
[...]

 

[ortolojf]

Ok ok spout

Il faut celà aussi pour afficher les données ( théoriquement fiables ) de la bdd, et des traitements des data du site ?

Tout mon site est en programmation orienté objet depuis longtemps.

Il est aussi modularisé, dans le sens où les scripts et classes php sont organisés par fonctionnalités.

C'est une protection tout azimut ?

Merci beaucoup spout.

 

[spout]

Vu que tu n'es pas censé avoir appliqué de htmlspecialchars() lors de l'enregistrement en DB, oui même ce qui viens de la DB doit être "échappé" lors de l'affichage.
Tu peux faire un helper/alias de htmlspecialchars() => h() comme CakePHP pr avoir plus facile.

 

[ortolojf]

Merci beaucoup spout

Bon ben je vais arranger mon orm maison d'accès à la bdd.

 

[ortolojf]

Bonjour spout

Je suis en train d'arranger mon orm, et j'ai une difficulté pour la syntaxe JOIN ON.

ON précède la condition de jointure.

Cette condition peut-elle inclure des variables ?

Merci beaucoup.

 

[ortolojf]

Bof...

Mon orm actuel ( avant l'intégration de prepare réels ), ne prend en compte les JOIN ON ( toutes formes de JOIN ) qu'avec des conditions sur colonnes de tables.

J'avais déjà mis des prepare partout, ( sauf les INSERT, UPDATE, etc... ), mais sans marqueurs.

Cà ne protège pas contre les hacks.

Je suis en train de générer les SQL prepare avec les marqueurs, quels que soient l'utilisation.

Le programme fait 6800 lignes actuellement.

Amicalement.

 

[ortolojf]

Bon.

Le programme fait plus de 9000 lignes.

Comment se présentent les fonctions prepare(), bindparam() et execute() des agrégats SQL ?

Par exemple :

prepare : "SELECT MAX(NUMCH) FROM CHEVAUX WHERE NOMCH=:nomch";

Quels bindparam() et execute() dans ce cas ?

Merci beaucoup spout.

 

[ortolojf]

Bonjour

Voici une instruction SQL préparée avec $tmp_statement puis bindParam sans le type, puis execute().

J'ai cette erreur systématiquement.

J'ai tout essayé : bindParam() , bindValue() avec et sans type.

Les marqueurs nommés sont incrémentés automatiquement dans le prepare.


Le problème ne produit qu'avec des limite et offset.

Merci beaucoup de votre aide.

             $this->_PDOInstance->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
                                        $this->_PDOInstance->setAttribute( PDO::ATTR_EMULATE_PREPARES, false);
                                        $this->_PDOInstance->setAttribute(PDO::ATTR_STRINGIFY_FETCHES, false);
                                        $this->_PDOInstance->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);

        $tmp_statement = SELECT DISTINCT ID FROM `COURSES` WHERE ID BETWEEN :ID AND :ID ORDER BY `ID` ASC LIMIT :offset, :limit

Array
(
    [:ID1] => 2201010101
    [:ID2] => 2404050608
    [:offset1] => 0
    [:limit1] => 45000
)


Fatal error: Uncaught PDOException: SQLSTATE[HY093]: Invalid parameter number in /var/www/html/php/config/Cache_MySQL/new_library_orm.php:905
Stack trace:
#0 /var/www/html/php/config/Cache_MySQL/new_library_orm.php(905): PDOStatement->execute()
#1 /var/www/html/php/config/Cache_MySQL/new_library_orm.php(2233): Database->execute()
#2 /var/www/html/php/config/Cache_MySQL/new_library_orm.php(2699): Database->CONSTRUCT_SQL()
#3 /var/www/html/construct_sitemap.php(164): Database->COMMIT()
#4 /var/www/html/construct_sitemap.php(170): SITEMAP->__construct()
#5 {main}
  thrown in /var/www/html/php/config/Cache_MySQL/new_library_orm.php on line 905

 

[ortolojf]

Excusez-moi.

Celà vient probablement d'une mauvaise correspondance de noms entre le prepare et les bindValue().

Je vais investiguer.