rivendel.org

Categorías:
Colegas:
Archivos:
<Marzo 2020
Lu Ma Mi Ju Vi Sa Do
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Documentos:

Maelmori

Se define escuetamente como "programador web", pero por supuesto es mucho más: dibuja realmente bien, escribe juegos de rol, ofrece interesantes reseñas de comics y aún le queda tiempo para hacer experimentos con SVG y ofrecer pequeñas joyitas de código desde su página.
2002-12-22 14:51 | Archivado en Colegas | 18 Comentario/s | URL permanente

Referencias (TrackBacks)

URL de trackback de esta historia http://rivendel.blogalia.com//trackbacks/4349

Comentarios

1
De: Maelmori Fecha: 2002-12-23 18:44

Hala! Me he puesto colorao! ;)
Feliz andadura con la web, ya iba siendo hora!



2
De: edmz Fecha: 2002-12-23 23:26

Sería mas joyita si sacara "strong" y "em" en vez de "b" e "i"



3
De: mur0 Fecha: 2002-12-27 17:04

¡Ahí le duele! ;-)

Afortunadamente el maestro Maelmori incluye un "se aceptan sugerencias" que, en el caso de ser tan sencillas y justificables como esta, supongo aceptará gustoso. ¿Habrá futuras versiones o fue sólo un 'Quick & Dirty?



4
De: Maelmori Fecha: 2002-12-27 18:51

En realidad eso depende de la versión del IE que tengas instalada. En el curro me saca EM y STRONG, aunque en mayúsculas (tengo IE 5.5 WIN) En otro sitio, no me acuerdo donde, probé y me salió un galimatías ininteligible donde debía de haber una simple negrita. Es un Quick and Dirty. Lo uso en el curro, una versión muy levemente modificada, por que no me ha dado problemas hasta ahora, y por que me resulta muy sencuillo de implementar. Luego en servidor elimino con PHP todas las etiquetas y atributos que no me hacen gracia y me quedo con las cuatro de los botoncitos (ul, ol, li, b o strong, i o em y cuatro más)
Hay en PHP.net una discusión larga e interesante sobre la eliminación de las etiquetas en entradas de este tipo.
http://www.php.net/manual/en/function.strip-tags.php
Es importante, no solo por la elegancia del código resultante si no por que puede dar lugar a un agujero de seguridad del tamaño de minesota, con cert advisory y todo (http://www.cert.org/advisories/CA-2000-02.html)
Pues eso os cuanto ;)



5
De: Maelmori Fecha: 2002-12-27 19:10

¡Ah!, sólo una cosa, pero importante: el control de las etiquetas que se quedan y las que se van DEBE hacerse en el servidor, no en el cliente. Si se hace en el cliente, será sencilla de saltar por necesidad (se puede deshabilitar javascript, o mandar el formulario a través de la URL como si fuera por GET, lo que sea...). Si se hace en el servidor será más dificil, por que siempre pasará una validación que no se podrán saltar desde cliente (en principio). TODA validación de entrada de datos debe ir siempre en el servidor. siempre siempre siempre. Si se hace además en cliente es una simple cuestión de facilidad para el usuario final (para no tener que cargar de nuevo la página y que diga simplemente "le falta el código postal"). Pero debe de volver a validarse en el servidor. Uno nunca debe fiarse de la validación del cliente por que siempre es "falseable". Y más cuando es susceptible de que nos puedan hacer una jugarreta, como es este caso.
Leeros la discusión de php.net, está muy muy bien.



6
De: kusor Fecha: 2002-12-28 01:24

Joer Maelmori, que estamos en navidad!.
En cuanto a las etiquetas de formato, e son perfectamente válidas para determinadas DTDs, ¿o no?. Pues eso, que sigue siendo perfectamente lícito usarlas y perfectamente lícito no hacerlo.
MovableType también emplea esas etiquetas en sus atajos de publicación, y eso no le resta calidad.
Yo, como soy así de delicao, modifiqué los fuentes una vez, para que pusiera y , pero es un coñazo tener que estar modificando el código a cada actualización ... y sigo aprendiendo Perl, a ver si me hago un plugin y listo Calixto.

Oyes, que Feliz Navidad!.



7
De: kusor Fecha: 2002-12-28 01:27

Como véis, he abierto ciertas etiquetas en el comentario anterior y no las he cerrado porque pensaba que no se permitía HTML en los comentarios. Pero ya veo que sí. Hablando de agujeros de seguridad...



8
De: rvr Fecha: 2002-12-28 12:23

Creo que el concepto de "agujero de seguridad" en ese caso está cogido con pinzas. Añadiendo HTML malicioso a un comentario lo más que se puede hacer es:

A) Engañar a otros usuarios a la hora de poner comentarios (y vamos, que la gente no es tontaina y no va dando su VISA así como así); o

B) Causar un pequeño desastre en el renderizado de la peich correspondiente.

kusor: En Blogalia se permite HTML tanto en comentarios como en historias.



9
De: kusor Fecha: 2002-12-29 01:28

Hombre, que no lo he dicho para molestar. A ver, aclaro la intención: lo peor que se puede hacer en un weblog con elementos HTML es colocar un iframe con algún tipo de publicidad o similar. Y sí, la gente no es tonta y no dá su número de VISA por ahí.
Ahora bien, ¿se permiten etiquetas de php? - evidentemente, no voy a hacer la prueba - si fuese el caso, no creo que hiciese mucha gracia que alguien pudiese listar en una página los contenidos de ciertos archivos.
De cualquier modo, reitero que mi intención no era molestar, que era una broma en relación con mi desconocimiento del sistema de comentarios de blogalia y el desastre que lié unos cuantos comentarios más arriba, sólo eso.



10
De: rvr Fecha: 2002-12-29 03:25

kusor: No hay problemas, hombre, faltaría más (y si falta más, me das un guantazo electrónico y en paz ;)

No, no se permite código PHP, eso sí que sería un agujero de seguridad, que comprometaría los datos. No se hace un 'eval' de las plantillas, historias o comentarios. Solo se sustituyen las macros [{negrita}}], etc.

De todas formas, voy a poner eso de los strip en la cola del TODO, aunque ahora tienen prioridad otros asuntillos.



11
De: kusor Fecha: 2002-12-30 01:58

Oido cocina!, no problem ;-).

Por cierto, he leido que os mudáis a scoop, mucha suerte con el trasiego del cambio.



12
De: mur0 Fecha: 2002-12-30 17:16

¡Joer, no se os puede dejar solos! :-)
De momento no tengo noticias de vulnerabilidades serias en Blogalia, y como bien apunta Maelmori, toda validación se realiza en el servidor (¿1er Consejo para un Website Seguro?).

PD: ¿Lo de scoop no era una inocentada?



13
De: rvr Fecha: 2002-12-30 20:08

Sí, lo de scoop era una inocentada O:)



14
De: Maelmori Fecha: 2002-12-31 13:55

¡La que tenenos montada, si!
Eso. Que en si no es una vulnerabilidad seria, pero se puede combinar con otras, que es el verdadero problema. Se puede meter código maligno en un script (no sólo en la etiqueta <script> si no también en un <img src="javascript:codigoChungo"> o en un onmouseover o incluso en un onload de la imagen.) Una vulneravilidad no tiene por que ser necesariamente un supervirus megachungo o robar el numero de la VISA para comprar explosivos plásticos: que venga un gracioso a poner un simple popup en tu sitio por las buenas es ya una intrusión bastante molesta...
Un saludete!



15
De: kusor Fecha: 2002-12-31 20:42

Pero una inocentada mucho mejor que el "awarfulpocket". ;-)
Feliz Año!!!!



16
De: mur0 Fecha: 2003-01-01 19:40

Siguiendo (poco) con el tema, podría ser conveniente utilizar en los comentarios el mismo sistema de macros que se usa para publicar historias. Suelo usar Mozilla con anti Pop-ups, si alguien detecta 'instrusismo' que avise :-)

Kusor: sobre lo del awarfulpocket, estuve a punto de mearme de risa cuando alguien picó en los comentarios de blogpocket x'D



17
De: rvr Fecha: 2003-01-03 01:54

Maelmori: En caso de algún comentario molesto, se puede borrar. Vamos, que me parece bien y lo tengo anotado en el TODO, pero ahora tienen prioridad otras cosas ;-)

mur0: Los comentarios utilizan el mismo sistema de macros que las historias ;-) negrita



18
De: mur0 Fecha: 2003-01-03 16:37

>> Los comentarios utilizan el mismo
>> sistema de macros que las historias

Entonces no hay problema con posibles iframes, javascripts puñeteros ni similares... Sí señor, un edificio sencillo pero robusto, este Blogalia.

Siga así, casero (si necesita peones de 2ª avise) ;-)



© 2002 - 2003 rivendel.org - Publicado bajo licencia Creative Commons License
Powered by Blogalia Blogalia