OVH Cloud OVH Cloud

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

24 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 !!!!

4 réponses

1 2 3
Avatar
Simon Marechal
Nicob wrote:
Il y a même certaines applis PHP qui "émulent" le register_globals à
On en important tout ce qui est en GET/POST/Cookie dans le namespace
global. Juste histoire d'être sûr que le pauvre webmestre ait son appli
qui marche du premier coup ...


http://fr.php.net/manual/en/function.import-request-variables.php

Une fonction php qui fait ça. Un bon truc à grepper pour trouver les
meilleures applications du net ...

Sinon la margarita ça allait, c'est de l'eau avec du sucre :)

Avatar
Adrieno
On 06 Jun 2005 14:33:21 GMT, "Adrieno" :

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


Pour répondre indirectement à Dominique, j'imagine que tu utilise
Flash pour la même raison que la plupart des webmasters : parce que
c'est à la mode.
Idem pour XML, d'ailleurs, si ça se trouve.



Que ce soit à la mode, c'est une chose, que cela réponde
immédiatement à mes besoins c'en est une autre. N'allons donc pas
trop vite en besogne à propos de flash.
Il y a un tel dénigrement de flash qu'au final, ce que les gens
retiennent c ce que dit Cedric Blancher (cf plus haut) : "c'est bien
pour faire des mickeys qui font coin-coin en dansant la polka, mais pas
plus"

Sans vanter les mérites de flash, je pense que c'est un peu etroit
comme facon de voir les choses. Il faut peser le pour et le contre de
chaque solution et trancher au regard de l'application proposé et du
public visé. C'est ce que j'ai fait, et j'ai tranché pour Flash.

Idem pour XML, d'ailleurs, si ça se trouve.


oui oui tout à fait, et idem pour PHP aussi :)


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


Première question : pourquoi veux-tu empêcher le téléchargement ?
Deuxième question : de quel budget disposes-tu pour empêcher le
téléchargement ?


1ere question : c'est un choix inherent au service proposé.
2eme question : 0 euros :) clairement. et puis c'est à but non
lucratif. Je ne compte pas investir dans un truc qui n'est pas censé
couvrir mes frais de depart.
Et quand je parle d'investissement, c lourd ( 7000 euros pour Flash Com
Server par exmple qui est d'ailleurs facilement cassable avec Net
transport)



Si passer outre un streaming en vidéo peut être un peu délicat (mais
plus pour longtemps), en revanche, il est toujours possible d'obtenir
un MP3 à partir d'un streaming sonore, et bien souvent sans perte de
qualité -- ou du moins, sans perte de qualité audible.
La solution la plus simple : télécharger le flux HTTP.
Si le flux n'est pas en HTTP, il sera peut-être dans un format que Net
Transport saura télécharger.
Si vraiment on ne peut pas télécharger le flux, mais uniquement le
faire arriver sur la carte son, on peut intercepter le son
(décompressé) avec Total Recorder (qui sert de driver intermédiaire).
Au pire, on peut toujours enregistrer ce qui sort de la carte son,
sans perte de qualité audible si on a investi 25 euros dans une bonne
carte son.


Je partage completement ce que tu dis. Evidemment dans le principe on
peut intercepter le flux sans peine.

Mais moi je ne cherche pas à atteindre un niveau de sécurité ultra
méga elevé.
Il s'agit simplement de protéger un tant soit peu les fichiers mp3 que
je propose en écoute... sans que ca n'impose de contraintes à
l'utilisateur final.

Pour l'instant, j'estime que d'un pt de vue de sécurité, il est
intolérable de pouvoir appeller un script envoyer_mp3.php qui renvoie
le mp3 directement le fichier à l'utilisateur.



Au finale, forcer le streaming, c'est un peu comme empêcher la copie
d'un logiciel : la seule façon, c'est de faire en sorte que la valeur
du contenu soit inférieure à l'effort nécessaire pour casser la
protection. En d'autres termes, fais de la merde, et personne ne
tentera de la copier/télécharger.


:)

Je m'y attellerai ! promis :)


Avatar
Fabien LE LEZ
On 08 Jun 2005 11:10:35 GMT, "Adrieno" :

Cela dit, doit-on pour autant rester les bras croisés
et contraindre les gens à télécharger les mp3 avant de pouvoir les
écouter ?


Pas tout saisi, là...
Tu veux contraindre les gens en leur interdisant le téléchargement, ou
leur faciliter la vie en leur donnant l'opportunité d'écouter les MP3
en streaming, quitte à ce qu'ils téléchargent s'ils le veulent ?

J'imagine que tu veux forcer le streaming (sinon tu ne posterais pas
ici), mais dans ce cas il ne faut pas prétendre que c'est pour
faciliter la vie des visiteurs.

Avatar
Adrieno
On 08 Jun 2005 11:10:35 GMT, "Adrieno" :

Cela dit, doit-on pour autant rester les bras croisés
et contraindre les gens à télécharger les mp3 avant de pouvoir les
écouter ?


Pas tout saisi, là...
Tu veux contraindre les gens en leur interdisant le téléchargement, ou
leur faciliter la vie en leur donnant l'opportunité d'écouter les MP3
en streaming, quitte à ce qu'ils téléchargent s'ils le veulent ?



Fabien, je me suis peut etre mal exprimé mais je répondais au post de
dominique blas qui trouvait que l'usage du mot "streaming" dans mon
contexte etait deplacé et qu'il y avait des serveurs de streaming pour
ca.

Je lui ai alors dit que ce n'est pas parcequ'on a pas de serveur de
streaming qu'on ne peux pas pour autant faire du streaming et qu'on
peut eviter de contraindre l'utilisateur de rester attendre le
téléchargement complet du fichier mp3 avant de commencer à le jouer.


1 2 3