Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

SVP Urgent : 3 questions concretes sur la securite PHP, readfile() et les tests de validation.

7 réponses
Avatar
Adrieno
Bonjour à tous,

Je suis en train de développer une application en PHP XML ET FLASH.

Concrètement, c'est un lecteur de mp3 en streaming. (Le
téléchargement de mp3 n'est pas permis). Ce sont des fichiers
relativement petits ( 40 sec / 200 Ko en moyenne)

La liste des fichiers (la playlist) qui s'affiche sur mon Appli flash
est définie dans un fichier xml qui est de la forme :


<?xml version="1.0" encoding="UTF-8"?>
<song>
<title>Musique_techno</title>
<file>envoyer_mp3.php?id=1</file>
</song>

<song>
<title>Musique_jazz</title>
<file>envoyer_mp3.php?id=2</file>
</song>

La page envoyer_mp3.php se charge de renvoyer le fichier mp3 demandé
en header.
En voici un extrait :

//le repertoire 'protect' est sécurisé coté serveur à l'aide d'un
htaccess.
if ($_GET['id']==2) $filename="protect/jazz.mp3";

header('Content-Type: audio/mpeg', true);
header('Content-Length: ' . filesize($filename), true);
readfile($filename);
exit;


A partir de la j'ai 3 questions très concrètes, votre aide me sera
TRES utile :

1. L'utilisateur mal intentionné qui edite le fichier xml et copie le
lien et colle sur sa barre d'adresse :
"www.monsite.com/envoyer_mp3.php?id=2" peut récuperer le fichier mp3
puisqu'il est envoyé en header. Comment contourner cette faille ?
J'ai pensé à tester le HTTP_REFERER mais, il n'y a jamais de
HTTP_REFERER, que l'on appelle le script à partir du fichier xml ou à
partir de la barre d'adresse ca change rien. Donc je ne sais pas
comment contourner une telle faille ...

2. J'utilise ici, pour lire mes fichiers mp3, la fonction readfile().
Est ce que cette fonction est "gourmande" en ressources serveur ? (il
est question qu'il y ait plusieurs dizaines d'utilisateurs en même
temps. Les fichiers étant relativement légers)
J'ai vu qu'il y avait d'autres fonctions equivalentes comme freads(),
ou fpassthru(), sont elles plus "efficaces" ? Laquelle est optimisé
pour cette utilisation ? Pourquoi ?

Et enfin :

3. Comment fait on pour tester une application avant mise en ligne ?
L'idée est simuler un environnement de connections multiples
(plusieurs dizaines) à cette application afin d'en tester la
résistance.
En fait, j'aimerai m'assurer de la stabilité de l'application avant
mise en ligne. Savoir par exemple, jusqu'à combien d'utilisateurs
peuvent se connecter simultanément. Je voudrais également m'assurer
qu'il n'y a pas de bug annexes au delà d'un certain de connectés...
Si vous avez des idées, elles sont les bienvenues !!!


MERCI INFINIMENT !!!!

7 réponses

Avatar
Guillaume Bouchard
Adrieno wrote:
Bonjour à tous,


Bonjour.

Je tient juste à faire une parenthèse.

- J'ai approuvé ce message pour une seul raison, l'information demandée
concernant read() et autres. Le reste, qu'il soit codé en php, python,
java ou brainfuck (http://en.wikipedia.org/wiki/Brainfuck) releve d'un
problème de conception independant du langage.
- On ne met pas SVP Urgent dans un titre de message. Ce n'est pas une
hotline, mais un newsgroup modéré et comme le disait un sage (:) "Il n'y
a rien d'urgent, que des choses en retard"
- j'ai repondu au meme message sur fr.comp.securite. On ne poste jamais
plusieurs fois le même message sur plusieurs forums, mais une seule fois
sur plusieurs avec le suivi sur un seul.

La liste des fichiers (la playlist) qui s'affiche sur mon Appli flash
est définie dans un fichier xml qui est de la forme :


<?xml version="1.0" encoding="UTF-8"?>
<song>
<title>Musique_techno</title>
<file>envoyer_mp3.php?id=1</file>
</song>

<song>
<title>Musique_jazz</title>
<file>envoyer_mp3.php?id=2</file>
</song>


Pour faire plus propre, pourquoi ne pas juste donnée l'id dans le
fichier XML.

if ($_GET['id']==2) $filename="protect/jazz.mp3";

header('Content-Type: audio/mpeg', true);
header('Content-Length: ' . filesize($filename), true);
readfile($filename);
exit;


Bon, j'espere que tu ne fais pas un if pour chaques fichiers, tu ne
seras pas arrivé avant longtemps sinon.

$files = array(1 => 'techo.mp3','jazz.mp3');
$filename = $file[$_GET['id']]

1. L'utilisateur mal intentionné qui edite le fichier xml et copie le
lien et colle sur sa barre d'adresse :
"www.monsite.com/envoyer_mp3.php?id=2" peut récuperer le fichier mp3
puisqu'il est envoyé en header. Comment contourner cette faille ?


Tu ne peux pas. À partir du moment où le fichier est envoyer en clair
via http, le client en fait ce qu'il veut.

2. J'utilise ici, pour lire mes fichiers mp3, la fonction readfile().
Est ce que cette fonction est "gourmande" en ressources serveur ?


Jamais entendu dire du mal de readfile(), mais je ne m'avancerais pas.

3. Comment fait on pour tester une application avant mise en ligne ?


Je dirais AB (apache bench) mais le problème c'est que tu utilise du
flash. Bref je n'en sais trop rien.

MERCI INFINIMENT !!!!


Pas besoin de hurler.

PS: renseigne toi sur les pratiques dans les newsgroups.

--
Guillaume.

Avatar
Olivier Miakinen

Je suis en train de développer une application en PHP XML ET FLASH.

Concrètement, c'est un lecteur de mp3 en streaming. (Le
téléchargement de mp3 n'est pas permis).


Tiens ? Quand tu dis que « le téléchargement » n'est pas permis, tu veux
dire que tu veux empêcher l'utilisateur de sauver sur son disque le
fichier mp3 qu'il aura reçu pour l'écouter, c'est bien ça ?

Comment comptes-tu faire ça ?

[...]

A partir de la j'ai 3 questions très concrètes, votre aide me sera
TRES utile :

1. L'utilisateur mal intentionné qui edite le fichier xml et copie le
lien et colle sur sa barre d'adresse :
"www.monsite.com/envoyer_mp3.php?id=2" peut récuperer le fichier mp3
puisqu'il est envoyé en header. Comment contourner cette faille ?


Bof. Est-ce vraiment une faille ?

L'utilisateur vraiment mal intentionné, à partir du moment où son
navigateur a récupéré le fichier pour le faire jouer, saura le sauver
sur disque sans aucun problème. D'ailleurs la plupart du temps il est
*déjà* sur son disque (en cache).

J'ai pensé à tester le HTTP_REFERER mais, il n'y a jamais de
HTTP_REFERER, que l'on appelle le script à partir du fichier xml ou à
partir de la barre d'adresse ca change rien. Donc je ne sais pas
comment contourner une telle faille ...


Comme pour les images, il doit exister quelques moyens mais aucun n'est
parfait. Au mieux cela ralentit les apprentis-crackeurs, et au pire
cela emmerde les utilisateurs normaux (cf. anti-clic droit contre la
récupération d'images).

2. J'utilise ici, pour lire mes fichiers mp3, la fonction readfile().
Est ce que cette fonction est "gourmande" en ressources serveur ?
[...] il y avait d'autres fonctions equivalentes comme freads(),
ou fpassthru(), sont elles plus "efficaces" ?


Je parierais que c'est kif-kif. En tout cas, tu es le seul à pouvoir
répondre à la question car il est très possible qu'une fonction soit
plus rapide qu'une autre dans un certain environnement, et plus lente
dans un autre.

En résumé : si tu as du temps à perdre, fais toi-même les tests de
performance en grandeur réelle ; sinon, choisis la fonction la plus
simple et la plus lisible pour la maintenance.

3. Comment fait on pour tester une application avant mise en ligne ?


Avoir un serveur en local ? Ou bien la mettre en ligne, mais sans
publier l'URL ?

L'idée est simuler un environnement de connections multiples
(plusieurs dizaines) à cette application afin d'en tester la
résistance.
En fait, j'aimerai m'assurer de la stabilité de l'application avant
mise en ligne. Savoir par exemple, jusqu'à combien d'utilisateurs
peuvent se connecter simultanément. Je voudrais également m'assurer
qu'il n'y a pas de bug annexes au delà d'un certain de connectés...


Je passe.

--
Olivier Miakinen
Non, monsieur le juge, je vous le jure : jamais je n'ai cité
Bruxelles dans ma signature.

Avatar
Thibaut Allender
Concrètement, c'est un lecteur de mp3 en streaming. (Le
téléchargement de mp3 n'est pas permis).


Tiens ? Quand tu dis que « le téléchargement » n'est pas permis, tu veux
dire que tu veux empêcher l'utilisateur de sauver sur son disque le
fichier mp3 qu'il aura reçu pour l'écouter, c'est bien ça ?

Comment comptes-tu faire ça ?


en flash j'imagine, c'est dans l'intro, mais ça se "crack" en 5 secondes
avec un soft genre swf decompiler

1. L'utilisateur mal intentionné qui edite le fichier xml et copie le
lien et colle sur sa barre d'adresse :
"www.monsite.com/envoyer_mp3.php?id=2" peut récuperer le fichier mp3
puisqu'il est envoyé en header. Comment contourner cette faille ?



Bof. Est-ce vraiment une faille ?


c'est une faille si on peut connaitre l'url de ce XML que seul flash
devrait connaitre
mais encore une fois, un petit coup de decompiler et vogue la galere...

L'utilisateur vraiment mal intentionné, à partir du moment où son
navigateur a récupéré le fichier pour le faire jouer, saura le sauver
sur disque sans aucun problème. D'ailleurs la plupart du temps il est
*déjà* sur son disque (en cache).


pas si c'est flash qui l'a chargé

J'ai pensé à tester le HTTP_REFERER mais, il n'y a jamais de
HTTP_REFERER, que l'on appelle le script à partir du fichier xml ou à
partir de la barre d'adresse ca change rien. Donc je ne sais pas
comment contourner une telle faille ...


Comme pour les images, il doit exister quelques moyens mais aucun n'est
parfait. Au mieux cela ralentit les apprentis-crackeurs, et au pire
cela emmerde les utilisateurs normaux (cf. anti-clic droit contre la
récupération d'images).


on peut tester le UA, mais je ne sais pas ce que renvoie flash lors
qu'on fait un getURL... User-Agent vide ?
mais bon, encore une fois, ça ou pisser dans un violon...

--
thibaut allender | freelance | http://capsule.org


Avatar
Adrieno

Je suis en train de développer une application en PHP XML ET FLASH.

Concrètement, c'est un lecteur de mp3 en streaming. (Le
téléchargement de mp3 n'est pas permis).


Tiens ? Quand tu dis que « le téléchargement » n'est pas permis, tu veux
dire que tu veux empêcher l'utilisateur de sauver sur son disque le
fichier mp3 qu'il aura reçu pour l'écouter, c'est bien ça ?

Comment comptes-tu faire ça ?



Cela ne se voit pas sur l'extrait du fichier envoyer_mp3.php que j'ai
inclu à mon premier post mais en entete, il y a d'autres fonctions
header permettant la gestion du cache comme suit :

/**Nouvel extrait de envoyer_mp3.php un peu + complet**/

session_cache_limiter('no-store'); // precedant un session_start();

header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // date d'expiration
dépassé
header("Cache-Control:no-store, must-revalidate");

if ($_GET['id']==2) $filename="protect/jazz.mp3";

header('Content-Type: audio/mpeg', true);
header('Content-Length: ' . filesize($filename), true);
readfile($filename);
exit;

/***** Fin extrait ********/

Avec ces header, le fichier n'est plus visible dans le cache du
navigateur aussi bien avec IE que Firefox ...
Mais bon !Ne nous en rejouissons pas trop vite , c'est un sécurité
toute relative... l'utilisateur mal intentionné ( et surtout forcené)
pourra récuperer le fichier sans trop de peine.

D'ailleurs, tu verras sur les thread sur les fonctions header() que
leur utilisation n'est pas rigoureuse. Selon les environements ca donne
des resultats différents.





[...]

A partir de la j'ai 3 questions très concrètes, votre aide me sera
TRES utile :

1. L'utilisateur mal intentionné qui edite le fichier xml et copie le
lien et colle sur sa barre d'adresse :
"www.monsite.com/envoyer_mp3.php?id=2" peut récuperer le fichier mp3
puisqu'il est envoyé en header. Comment contourner cette faille ?


Bof. Est-ce vraiment une faille ?


Bein pour quelqu'un qui ne veut protéger ses mp3, evidemment que c'est
une faille.
Si on appellait ce script à partir via un lien http, on pourrait faire
un test sur le HTTP_REFERER et empecher l'envoi si le HTTP_REFERER ne
correspond pas au domaine ...
C'est pas la panacée, mais c'est toujours plus sécurisé qu'une
fenetre "Save as" qui s'ouvre à l'appel du script.



L'utilisateur vraiment mal intentionné, à partir du moment où son
navigateur a récupéré le fichier pour le faire jouer, saura le sauver
sur disque sans aucun problème. D'ailleurs la plupart du temps il est
*déjà* sur son disque (en cache).


Cf plus haut.


Avatar
Nicklas
Il n'y a pas de solution dans ton cas.

Si flash accède à ton fichier, il est sur le disque (au moins dans le
cache).

Si le fichier mp3 arrive sur le PC client, il suffit de sniffer le réseau
pour le trouver...

La seule solution que je verrai :

- crypter tes fichiers MP3 sur le serveur.
- coder un algo dans ton animation Flash
- flash récupère le fichier
- le décrypte
- puis le lit

Mais ce n'est pas 100% fiable, car Flash peut être décompilé...
et on peut récupérer l'algo.

Nicklas
Avatar
TiChou
Dans le message <news:,
*Thibaut Allender* tapota sur f.c.l.php :

je ne sais pas ce que renvoie flash lors qu'on fait un getURL...
User-Agent vide ?


User-Agent: Shockwave Flash
x-flash-version: 7,0,19,0

fu2 fciwn

--
TiChou

Avatar
Nicolas ROBERT
Bonjour à tous,


bonjour,
Tu as eu pleins de réponses, sauf pour la partie 3.
OK, je m'y colle.

3. Comment fait on pour tester une application avant mise en ligne ?
L'idée est simuler un environnement de connections multiples
(plusieurs dizaines) à cette application afin d'en tester la
résistance.
En fait, j'aimerai m'assurer de la stabilité de l'application avant
mise en ligne. Savoir par exemple, jusqu'à combien d'utilisateurs
peuvent se connecter simultanément. Je voudrais également m'assurer
qu'il n'y a pas de bug annexes au delà d'un certain de connectés...
Si vous avez des idées, elles sont les bienvenues !!!


En fait, ce que tu cherches à faire, c'est un test de montée en charge.
Comme, on te l'as déjà écrit, il te faut installer ton appli sur un serveur
local.

Il te faut aussi un outil qui simulera une montée en charge de connexions
d'utilisateurs. je ne saurais trop te conseiller
que de voir du côté de l'outil de test de charge (gratuit) opensta:
http://www.opensta.org

C'est un peu complexe à mettre en place, mais avec un peu de perséverance,
tu arriveras à tes fins ;-)



MERCI INFINIMENT !!!!


mais de rien....