Sé que un enfoque de lista negra para el filtrado de URL no es el más seguro, pero digamos que además de este filtrado, también estamos reescribiendo todos los enlaces que no son de confianza para pasar por una página de redirección que advierte al usuario sobre los riesgos. y que estamos implementando la lista negra con cuidado para evitar Evasión de filtro XSS .
¿Qué esquemas de URL pondríamos en la lista negra? Los dos obvios son javascript: y data: , ¿qué otros me faltan?
Una lista negra de esquemas URI no es confiable.
No hay una lista común de esquemas URI incorrectos porque simplemente no es posible crear uno completo. Hay muchos esquemas no estándar para diferentes navegadores y se podrían agregar más en el futuro. (Un ejemplo de un esquema no estándar peligroso sería livescript: para versiones antiguas de Netscape).
Este es otro buen punto:
No permito bitcoin: en mis servidores, ni nada, excepto http, https, o ftp.
La razón es porque no tengo forma de saber qué tercero Las aplicaciones pueden tener vulnerabilidades (incluida la ingeniería social). que podría ser explotado por una cadena URI especialmente diseñada que se les suministra.
Del mismo modo, no hay una lista negra de etiquetas HTML peligrosas porque, aunque están estandarizados, los navegadores siguen con sus propias etiquetas. Construir una lista completa sería inútil.
Otro problema es que podría tener problemas con esquemas anidados. ¿Qué pasa con view-source:data:... , rss:jar:... , etc.?
Por lo tanto, es más seguro acordar una lista blanca de esquemas aceptables y agregar más a pedido. Por ejemplo, este es el valor predeterminado en Wordpress:
$protocols( array ) ( opcional ) Una matriz de protocolos aceptables. El valor predeterminado es 'http', 'https', 'ftp', 'ftps', 'mailto', 'news', 'irc', 'gopher', 'nntp', 'feed', 'telnet', 'mms', 'rtsp', 'svn', 'tel', 'fax', 'xmpp'si no está configurado.
Lea otras preguntas en las etiquetas web-browser url xss