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

On 07 Jun 2005 08:37:18 GMT, Nicob <nicob@I.hate.spammers.com>:

Limitation du débit au minimum nécessaire pour le streaming ?

Limitation de débit + interdiction de connexions multiples depuis la
même adresse IP, sinon ça ne sert à rien.
Et bien entendu, ça empêche plusieurs accès depuis des postes du même
LAN.

Je ne sais
plus quelle radio fait ça, mais ça décourage pas mal le dwld de bourrin ...

Bof... avec l'ADSL (connexion permanente), mettre 48 heures pour
télécharger un fichier ne dérange plus grand-monde.

Le Tue, 07 Jun 2005 08:59:55 +0000, Fabien LE LEZ a écrit :

Bof... avec l'ADSL (connexion permanente), mettre 48 heures pour
télécharger un fichier ne dérange plus grand-monde.

Si on doit attendre 48h pour pouvoir streamer la revue de presse du matin,
je pense que ça risque de déranger du monde.


--
BOFH excuse #207:

We are currently trying a new concept of using a live mouse. Unfortunately,
one has yet to survive being hooked up to the computer.....please bear
with us.

On 07 Jun 2005 09:01:30 GMT, Cedric Blancher
<blancher@cartel-securite.fr>:

Si on doit attendre 48h pour pouvoir streamer la revue de presse du matin,
je pense que ça risque de déranger du monde.

Certes, mais au pire, le téléchargement ira au moins aussi vite que le
streaming.

gomor-usenet@gomor.org wrote:

Si php.ini est configuré en register_globals = yes, en passant une
url

Vivement qu'il virent cette directive.

www.monsite.com/envoyer_mp3.php?id=bla&filename=/etc/passwd

Je pense que ca readfile() le /etc/passwd. Non ?

Normalement le safemode t'en empeche. Mais quoi qu'il arrive c'est une
connerie de ne pas initialiser ces variables !

--
Guillaume.

Cedric Blancher wrote:

PHP Nuke

Mouahahahahaha !!! T'as pas pire comme exemple ? ;-)

PhpBB ? Phorum ?

Vraiment beaucoup de failles phpbb tombent, mais je pense que le pire de
tous est de loin phpnuke. Tout est atroce dans phpnuke, pas une seule
ligne n'a été épargnée. En plus comme il fait le café ...

Le plus amusant est de voir comment certaines failles ont été réparées:

if(isset($admin))
{
$admin = base64_decode($admin);
$admin = addslashes($admin);
$admin = base64_encode($admin);
}

[coupe coupe]

function is_admin($admin) {
global $prefix, $db;
if(!is_array($admin)) {
$admin = addslashes($admin);
$admin = base64_decode($admin);
$admin = explode(":", $admin);


Incroyable non? Et c'est comme ça partout partout partout partout ...

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>

Hum. Nous avons un BIG problème conceptuel ici.

En effet, même si les fichiers musicaux sont situés hors de portée du
serveur Web ou, au minimum, dans un répertoire protégé, c'est à dire que
je ne peux, EN AUCUN CAS, taper www.machin.com/mp3/jazz.mp3
ils sont toujours à portée du serveur applicatif (PHP) et je peux donc
taper www.machin.com/envoyer_mp3.php?id=2 et j'ai mon fichier (mon
navigateur me demande même si je veux l'enregistrer sur le disque).
Hop, réglé. Y'a rien à voir. L'appli Flash n'est là que pour faire joli
et le téléchargement des mp3 a lieu en intégralité (on a même son ID3).


--

Au passage, le streaming ce n'est pas simplement bazarder un fichier à
l'instar d'une image servie par un serveur Web.
Parle-t-on de streaming lorsqu'on affiche une page web ?
Non, bien évidemment !

Le streaming fait appel a des techniques de mesure de la bande passante
(en temps réel) et de cache de manière à fluidifier le débit et
s'adapter en permanence aux conditions du réseau et à basculer en cas de
force majeure sur un protocole de base (comme HTTP) pour diffuser le
contenu.
C'est la raison pour laquelle il existe des serveurs de ... streaming.
Ce n'est pas que pour faire joli sur la carte de visite.

Rien n'interdit effectivement de développer un client de streaming en
flash mais bon ... à moins qu'il en existe un client incorporé (Flash 7)
je verrais plutôt ce genre de truc en java côté client.

--

M'enfin.
Reste à régler le pb de la sécurité : authentification, confidentialisation.

Avec un client dédié cela est plus simple car on peut alors donner
naissance à des échanges non standards, verrouillés et chiffrés.


--

Mais restons-en à notre couple navigateur serveur Web/applicatifs en
l'absence de rupture technologique.

A ce moment là, un minimum serait de codifier la structure de recherche
d'un morceau d'une manière un peu plus complexe que id=1, id=2, etc.

Ainsi si le fait de demander le fichier << jazz.mp3 >> conduit à appeler
le script envoyer_mp3.php avec l'argument ?idNf35a98bcf37d6c4e
il est déjà moins évident de trouver le morceau directement en tapant l'URL.
Bien entendu il faut éviter de placer l'URL dans le fichier XML. Ca
c'est une connerie !

Partant, si on tient à la liste de diffusion (play list) en XML, autant
que ce dernier comporte le nom en toutes lettres du fichier musical.
Charge au client (flash, Java, C++, PyGTk, Tcl/Tk, etc) de l'encoder
voire le chiffrer afin de le transmettre, accompagné de la requête, au
serveur applicatif sous une forme indéchiffrable.
Mais du coup qu'est ce qui interdit un utilisateur B de piquer le
fichier XML de l'utilisateur A qui a accès à davantage de fichiers
musicaux ?
Rien.
Et, avec le temps, tout le monde peut jouer tous les fichiers dispos.

Finalement, on revient, comme d'hab à une authentification (centralisée)
de l'usager ce qui permet au client (flash, Java, etc) de récupérer
confidentiellement la liste des mp3 autorisés, de l'afficher, de valider
le ou les choix de l'utilisateur et de diffuser ensuite les fichiers
musicaux sélectionnés.

Je ne vois pas très bien ce qu'apporte Flash dans ce domaine (on est
loin du traitement du son, de l'image et de séquences animées) à moins
qu'il comporte un client de stream (auquel cas il faudrait le serveur
associé).
Donc, ce serait, à mon humble avis, plus simple en Java et, du coup, ça
doit se trouver en regroupant différents sources éparpillés sur le Net.

db

--

Courriel : usenet blas net

[...]

À noter qu'il est très difficile d'interdire le téléchargement d'un
fichier, i.e. forcer le streaming. Même un vrai serveur de streaming
(style Real Video) ne résiste pas à Net Transport.

A partir du moment où l'on dispose d'un flux dans son intégralité, rien
ni personne ne pourra empêcher de l'enregistrer. C'est juste une
question de temps d'implémentation ou plus si le codage n'est pas public.

---

Je fais une digression sur le sujet de la capture et reconstitution des
flux (je ne peux pas m'en empêcher :-) ).

En audio-video les majors américaines ont imposé le HDSCP (prise HDMI)
qui est un codage de source (sonore/video) reposant sur une biclé.
Bien, magnifique.

Ok, ça interdit la copie bête et méchante du flux numérique.
Mais tant que nos oreilles seront analogiques toujours rien n'interdit
de coder le signal anologique en sortie de préampli (voir en sortie
d'ampli).
A moins que ces chers américains (et bientôt les européens) considérent
qu'enregistrer en sortie de préampli consitue un moyen de détournement
de la protection (sic) et donc une violation qui de l'EUCA ou du DMCA !

Ok, ce n'est pas aussi simple que d'activer la fonction de direct
numérique du lecteur CD et c'est encore plus compliqué en multicanal
(5:1, 6:1, 7:1) mais ce n'est qu'une question d'équipement (brancher un
multiplexeur en sortie d'ampli ça reste faisable) et si ce dernier n'est
pas, poru l'instant, à la portée de M. Tout le monde on n'oubliera pas
non plus que le dernier opus de la guerre des étoiles était disponible
quelques heures après la fin de la première projection publique. Ce
n'est pas monsieur Tout le monde qui pouvait se permettre de piquer le
film à sa source (chez un distributeur ou directement chez Lucasfilm).

Ok, ok, pour Stars War le jeu en valait la chandelle mais avec la
démocratisation des procédés M. Tout le monde pourra également encoder
facilement ses DVD 7:1, SACD et CD.

Encore un pas de plus vers la raréfaction des morceaux à faible
diffusion et un grand pas vers davantage d'homogénéisation planétaire !

db

--

Courriel : usenet blas net

On 06 Jun 2005 14:33:21 GMT, "Adrieno" <adrien.dain@gmail.com>:

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.

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 ?

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.

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.

"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
nfbda1doq1a0ve8erj8h4ae17cs1i72414@4ax.com...

Bonjour,

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

Je ne vois pas le rapport...

En d'autres termes, fais de la merde, et personne ne
tentera de la copier/télécharger.

Trés trés judicieux comme conseil...

Salutations.

Hum. Nous avons un BIG problème conceptuel ici.

En effet, même si les fichiers musicaux sont situés hors de portée du
serveur Web ou, au minimum, dans un répertoire protégé, c'est à dire que
je ne peux, EN AUCUN CAS, taper www.machin.com/mp3/jazz.mp3
ils sont toujours à portée du serveur applicatif (PHP) et je peux donc
taper www.machin.com/envoyer_mp3.php?id=2 et j'ai mon fichier (mon
navigateur me demande même si je veux l'enregistrer sur le disque).
Hop, réglé. Y'a rien à voir. L'appli Flash n'est là que pour faire joli
et le téléchargement des mp3 a lieu en intégralité (on a même son ID3).

Merci pour cette remarque pertinente Dominique.
Mais c'est un peu l'objet de ce thread. Ah si, tu nous apprends, que
"même son id3" est récuperé... je vois mal, comment il serait
possible -sans manipulations tordues de filtrages des entetes du
fichier- de récuperer un mp3 mais sans ses tags ID3...

--

Au passage, le streaming ce n'est pas simplement bazarder un fichier à
l'instar d'une image servie par un serveur Web.
Parle-t-on de streaming lorsqu'on affiche une page web ?
Non, bien évidemment !

Le streaming fait appel a des techniques de mesure de la bande passante
(en temps réel) et de cache de manière à fluidifier le débit et
s'adapter en permanence aux conditions du réseau et à basculer en cas de
force majeure sur un protocole de base (comme HTTP) pour diffuser le
contenu.
C'est la raison pour laquelle il existe des serveurs de ... streaming.
Ce n'est pas que pour faire joli sur la carte de visite.

Très bonne remarque. Ce n'est pas du streaming audio stricto sensu car
ca necessite des solutions adaptées qui engendrent des frais assez
impressionnants. 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 ? Non, bien évidemment ! Il y a moyen de contourner cette
contrainte puisque l'application actuelle permet d'écouter des
fichiers mp3, quelques soit leur taille, sans téléchargement "manuel"
au préalable. Les mp3 sont bufferisés dans la machine client et
l'écoute se fait en temps réel. C'est à ce titre que j'utilise le
mot streaming, ca fait joli si tu veux, mais ca corresponds à une
réalité.

Rien n'interdit effectivement de développer un client de streaming en
flash mais bon ... à moins qu'il en existe un client incorporé (Flash 7)
je verrais plutôt ce genre de truc en java côté client.

Mais restons-en à notre couple navigateur serveur Web/applicatifs en
l'absence de rupture technologique.

A ce moment là, un minimum serait de codifier la structure de recherche
d'un morceau d'une manière un peu plus complexe que id=1, id=2, etc.

Ainsi si le fait de demander le fichier << jazz.mp3 >> conduit à appeler
le script envoyer_mp3.php avec l'argument ?idNf35a98bcf37d6c4e
il est déjà moins évident de trouver le morceau directement en tapant l'URL.
Bien entendu il faut éviter de placer l'URL dans le fichier XML. Ca
c'est une connerie !

Partant, si on tient à la liste de diffusion (play list) en XML, autant
que ce dernier comporte le nom en toutes lettres du fichier musical.
Charge au client (flash, Java, C++, PyGTk, Tcl/Tk, etc) de l'encoder
voire le chiffrer afin de le transmettre, accompagné de la requête, au
serveur applicatif sous une forme indéchiffrable.
Mais du coup qu'est ce qui interdit un utilisateur B de piquer le
fichier XML de l'utilisateur A qui a accès à davantage de fichiers
musicaux ?
Rien.
Et, avec le temps, tout le monde peut jouer tous les fichiers dispos.

Finalement, on revient, comme d'hab à une authentification (centralisée)
de l'usager ce qui permet au client (flash, Java, etc) de récupérer
confidentiellement la liste des mp3 autorisés, de l'afficher, de valider
le ou les choix de l'utilisateur et de diffuser ensuite les fichiers
musicaux sélectionnés.

Je ne vois pas très bien ce qu'apporte Flash dans ce domaine (on est
loin du traitement du son, de l'image et de séquences animées) à moins
qu'il comporte un client de stream (auquel cas il faudrait le serveur
associé).
Donc, ce serait, à mon humble avis, plus simple en Java et, du coup, ça
doit se trouver en regroupant différents sources éparpillés sur le Net.

db

Avant de passer à flash, j'ai essayé la solution java.
Du point de vue du problème de téléchargement, c'est exactement le
meme problème.
Java c'est bien, mais c'est pas adapté à toutes les situations.

Déjà il faut avoir une console Java sur son pc ce qui n'est pas le
cas de beaucoup de gens. Son téléchargement est de 13 megas, et son
installation necessite plusieurs étapes de validation. Ce sont des
contraintes lourdes vu les futurs utilisateurs de mon online mp3
player.
Le choix du flash, permet au moins une installation rapide et
automatique du plug-in.
N'en deplaise à certains, le public visé par ton application oriente
forcément les choix technologiques vers une solution plutôt qu'une
autre.
Et puis, il faut arreter de véhiculer le cliché de flash comme étant
l'animation qui fait bouger des canards qui font coin-coin.
Flash est adapté aujourd'hui pour des applis très professionnelles.

Une solution que je retiens au probleme que j'ai posé sur ce topic,
consiste à crypter les fichiers mp3 coté serveur avec un algo, et
dans flash les decrypter et les diffuser.
De ce fait, meme si quelqu'un met la main sur les fichiers mp3 sur le
serveur. Il lui faudra l'algo de cryptage pour lire les fichiers (ce
qu'il pourra trouver sans trop de peine en decompilant le fichier swf
mais ca c'est un autre affaire.)

Cordialement

--

Courriel : usenet blas net