PHP Formulario de Seguridad Con Referer

Estoy armando un sitio en el que se hará disponible para la entrada de usuario. Me preguntaba si escribir una función como:

if(getenv("HTTP_REFERER") != 'http://www.myURL.com/submitArea'){
        die('don\'t be an jerk, ruin your own site');   
    }else{
        //continue with form processing    
    }

es suficiente para evitar el cruce sitio de los envíos.

EDIT: Y si no, ¿cuál es la mejor práctica para la prevención de las formas de ser enviados desde otros hosts?

  • Odio decirlo, pero tienes la respuesta incorrecta para esta gran pregunta. Por favor, lea mi post, tengo la evidencia de apoyo.
  • No, la respuesta es claramente erróneo. I puede forjar Referer encabezados y se un peligro para la seguridad.
  • no importa, esto no estaría sucediendo en su navegador, pero alguien del navegador.
  • Lo siento, pero no entiendo lo que estás diciendo. ¿Qué quiere decir este no se que pasa en mi navegador?
  • Si me pueden forjar las solicitudes en mi navegador, ¿cuál es el problema con la búsqueda de un navegador explotar (agujero) que me permitirá hacerlo en la gente de otros navegadores? Firefox / Chrome / Opera, todos ellos no son exactamente las balizas de seguridad. El sólo forma de trabajo es la de asumir que todo lo que se le entregó a usted (desde el navegador, cliente, otros sitios, base de datos) es completa y absolutamente papelera. Desinfecte sus datos y no deja ningún margen para el error. Si usted tiene una forma que tiene el potencial de lío con las cosas que usted siempre debe autenticar con algo control, como la SESIÓN.
  • Que significa que es seguro porque los navegadores de las reglas de juego. Y puede alterar su navegador y hacer que lo haga, pero no hay manera posible de que nunca podría ocurrir en algún otro navegador, a menos que fue deliberado.
  • Ah, ya veo. Pero usted debe nunca de confianza de la entrada del usuario – no importa qué!
  • Eso es básicamente lo que estamos recibiendo en sí. 😉
  • maldita sea esto es impresionante pregunta, y no me importa recibir el -3.
  • Franky, no hay forma de evitar que alguien de la presentación de los datos del formulario de «otro lugar». Si usted está hablando acerca de CSRF, a continuación, comprobar el Origen de encabezado o del uso de símbolos es la cosa correcta a hacer, pero no, no me impide enviar el formulario de valores a través de Telnet no importa cuánto lo intente. Sólo se puede construir a prueba de tontos tecnologías en la parte superior de su sistema para mantener a los críos de distancia.
  • si desea obtener respuestas por el código de la muestra, entonces siento que es una cuestión diferente por completo. Me gustaría proponer a sacarla de la pregunta (y opcionalmente post como uno nuevo), como la pregunta original ya creado un montón de discusión. Por favor, vamos a mantener centrado en el REFERER parte. Gracias.
  • este nuevo código, se considerarán una «deferencia enfoque en profundidad», sin embargo, tanto CSRF cheques podrán ser anuladas por una vulnerabilidad de XSS. Usted debe usar un número aleatorio como uniqid(mt_rand(), true), no el valor hash de la contraseña. Cabe señalar que hay muy poca evidencia para apoyar muchos de los argumentos de mi post.
  • La torre, Gracias de nuevo, me llevó fuera de la página, ya que en realidad es un conjunto de otros, la lata de gusanos. Pero hice lo que me sugeriste. En realidad, ahora voy con las cookies y almacena los identificadores de sesión utilizando el uniqid() método… el sitio no es necesario QUE seguro, así que espero que esto al menos frustra el promedio de hack.

6 Kommentare

  1. 3

    La verdad que sí, de acuerdo a la OWASP CSRF Prevención de la Hoja de Trucos en la mayoría de los casos la comprobación de referer es suficiente para parchear una vulnerabilidad CSRF. Aunque es trivial para suplantar el referer en su PROPIO NAVEGADOR es imposible para suplantar en otro navegador (a través de CSRF) porque rompe las reglas.

    De hecho la comprobación de referer es muy común ver en los hardware de red donde la Memoria es escasa. Motorola lo hace por su Tabla de surf de los Módems de Cable. Sé que esto de primera mano, porque He hackeado con csrf y luego se puso un parche mediante un referer de verificación. Esta vulnerabilidad recibido una gravedad métrica de 13,5 y de acuerdo con el Departamento de Seguridad Nacional esta es la más peligrosa vulnerabilidad CSRF jamás descubierto y en la parte superior de 1.000 más peligrosos defectos en el software de todos los tiempos.

    • la torre, muchas gracias por el envío de este. Voy a añadir todos los elementos suministrados en estas respuestas, pero al ver el «Referer BLOQUEADO BLOQUEADO BLOQUEADO BLOQUEADO» me hizo respirar un poco más fácil. gracias!
    • Estoy feliz de ayudar.
    • -1 para cada respuesta, excepto este.
    • Ah, maldita sea, aunque me suelen votar a la gente por lo que sugiere una vulnerabilidad de este caso específico no es bien conocida. Navegador web de Google sec manual es impresionante, todo el mundo debe leer.
    • Esta respuesta es MAL y debe ser evitado. Como mencioné en mi respuesta, debe utilizar algún método de autenticación.
    • Las reglas de la media de nada. Se viene desde el navegador o el usuario es debe jamás de los jamases ser de confianza. Que es como es.
    • después de pensar un poco, yo creo que la Torre es correcta. Cuando se trata de los navegadores y de seguridad, yo siempre asumir algunos del navegador, en algún lugar, va a tornillo de esto, pero por el google referencia, todos tienen derecho. Así que a menos que usted está hablando acerca de la costumbre de los ejecutables, o si quieres estar totalmente seguro-que es totalmente defendible — la comprobación de referer podría ser lo suficientemente buena.
    • Pero todo lo que se necesita es alguien que escribe sus propia navegador > y ¡puf! todo se va abajo en el humo. Además, el post que mencionas sólo cubre las llamadas AJAX.
    • Voy a recibir un correo electrónico sobre mi comentario de edición? Asegúrese de quitar la blasfemia (lo siento) pero es que el resto de verdad que horrible?
    • Incluso entonces, este bloque de inocentes clientes/servidores proxy, así que no envía a la espera referer de la configuración y la naturaleza.
    • Exactamente. No sé que mantiene upvoting esta respuesta es, definitivamente, y fundamentalmente equivocado.
    • De acuerdo. Es como decir que nunca necesita de agentes de la policía porque todo el mundo va a seguir las reglas. Asumir la nadie seguir las reglas y te sentirás mucho más seguro.
    • ¿Ustedes no entienden la diferencia entre código sospechoso puede hacer y lo que un usuario puede intencionalmente hacer para tornillo de sí mismo? Estoy seguro de que la única razón por la que no depende de referer sólo es debido a que algunas personas deshabilitar su referers debido a la paranoia.
    • De acuerdo a la gente de la lógica, si alguien utiliza un nonce en cada solicitud POST, yo podría modificar mi navegador de código remoto desde otros sitios se vaya a descubrir que nonce y utilizarla.
    • En el que caso de que esta solución sería la mierda. ¿Entiende usted que hay una diferencia entre en la teoría de la y en la práctica?
    • Según tú su la lógica no necesitamos ningún salvaguardias porque todos se van «las reglas de juego.»
    • K: lo Siento, pero no entiendo muy punto fundamental aquí. Que NO utilice su sitio web para obligar a alguien del navegador de suplantación de un referer. Si se puede, el navegador es ROTO, y por lo tanto inseguro.
    • Lo siento, igual que no se puede decir, atacar a alguien del equipo para crear un ataque DDOS? Hecho eso. No se puede instalar un caballo de troya que le permitirá modificar el navegador? Hecho eso. No se puede explotar un agujero de seguridad en el navegador? Hecho eso. Estoy totalmente de fallar para ver el mérito diciendo «no se puede hacer porque no es permitido. Si no puede, entonces está roto» cuando no de garantizar la validez de cualquier de entrada de usuario alguna. QUE es el punto fundamental aquí, no se si el navegador puede ser comprometida.
    • Atwood muchas Gracias, y en el resto de ustedes WOW yo no tenía ni idea de que esto iba a ser tan controvertida un todo el mundo debe leer el Navegador de Google sec manual, incluso si usted está de acuerdo conmigo.
    • Josh K. es absolutamente correcto. todo lo que puede ser hackeado será.
    • K, por favor lea la pregunta, la aceptó contestar, y vaya a leer sobre CSRF, y luego, de publicar algo, ya que ni siquiera están hablando en el contexto más… Lo que está defendiendo es completamente irrelevante. Un exploit es más de juego, ¿cuál es tu punto?
    • Por favor vuelva a leer mi muchos los comentarios. Mi punto es que si usted obtener información desde el navegador debe nunca de confianza. Nunca. Puedo ultra bold? ****Nunca****, ****nunca****. Supongo que no, pero espero que entiendas mi punto.
    • K, I leer todo de sus puestos. Ese punto es irrelevante en este contexto. Dudo que siquiera saben lo que es una CSRF.
    • Yo creo que todos estamos de acuerdo en que la cuestión de las necesidades de cambio en la redacción de cualquier manera. ¿Por qué no arreglarlo?
    • Edison: No, no.
    • Edison realmente ha sido muy modificada y me gusta cómo es.
    • Esto es incorrecto por dos razones. En primer lugar, el encabezado se omite a menudo. En segundo lugar, si el ataque CSRF que sucede en el real sitio, la url de referencia será la correcta. Por ejemplo, al colocar una imagen en el sitio real en algún área de comentarios puede lanzar un ataque CSRF. Aparte de eso, las reivindicaciones de algunas personas acerca de las reglas son irrelevantes. Ellos probablemente no entender lo que CSRF realmente es.
    • No en una petición post. Y la comprobación de un remitente no es realmente la «confianza» de entrada del usuario. Just sayin’.
    • Lo que usted describe es XSS.
    • Sellgren Lo que usted está describiendo, sería un método de pasar por esta CSRF sistema de seguridad específicamente para OBTENER basado csrf en algunos aplicaciones. Claramente este parche funciona bien para Motorola módems, pero si permiten imagen personalizada url asegúrese de usar el POST para importante los cambios de estado (por ejemplo cambiar la contraseña). Este uso de CORREOS vs CONSEGUIR es cubierto por el RFC 2616 partes 9.3 y 9.5, y sí, me doy cuenta de que la mayoría de las web de los desarrolladores de aplicaciones ignorar RFC de la.
    • Si el «Referer» puede ser falso (o eliminado), que va a ser. La comparación de un token de sesión con un POST token es más fácil y más seguro.
    • Es imposible de suplantar el Referer en algún otro navegador el uso de CSRF. He publicado la evidencia de apoyo, no la tienes.
    • No, lo que he descrito no tenía nada que ver con la vulnerabilidad de XSS. De hecho, no tenía nada que hacer con JavaScript o «secuencias de comandos». Era sólo el envío de peticiones en el nombre del usuario.
    • La torre Sólo si se está utilizando uno de estos navegadores. Supongo que tienes razón en que va a cubrir casi cualquier situación, pero ¿por qué este método si existe la posibilidad? ¿Y qué pasa si el encabezado REFERER ha sido ocultado? La única pega que puedo pensar para CSRF tokens de sesión es que requieren cookies para ser habilitado a menos que esté pasando identificador de sesión a través de la url. Sin embargo, CSRF generalmente sólo los objetivos priveleges de usuarios registrados. Si debe volver a generar el token para cada forma, parece completamente hackproof a mí. Aunque gracias por abrir mis ojos, me gustaría que me podría deshacer de mi downvote.
    • hmm en realidad estás en lo correcto, no XSS. Pero el referente método es seguro, siempre y cuando no dejes que la gente de publicar el link de una imagen para su autenticado páginas o usar el POST para autenticado acciones. Si sólo la web fue diseñada para ser segura 🙁
    • Es posible el uso de CSRF token en las cookies? ¿Tiene usted un ejemplo de esta práctica? AFAIK la única manera de hacerlo bien es enviar a través de GET/POST peticiones y generar uno nuevo cada vez. De cualquier manera usted todavía necesita una cookie para evitar que se cierre la sesión al cerrar la página y abrir una nueva. «¿Y qué pasa si el encabezado REFERER que ha sido oculto» de Usuario se bloquea.
    • Eso es exactamente por qué esta pregunta es tan impresionante! Creo que un montón de personas que han aprendido algo de esto (incluso Jeff Atwood!). Me fui por delante y se hizo una edición en la página si alguien quiere cambiar su voto.
    • Si estoy en lo correcto, CSRF tokens requieren cookies a menos que el uso de id de sesión en la url (generalmente se considera inseguro). La idea es que usted está comparando el token almacenado en la Sesión coincide con el que está incrustado en un campo oculto de la forma más POSTERIOR de los datos. Recuerde que el uso de sesiones almacena una cookie con el identificador de la sesión en la máquina del cliente, pero también puedes hacerlo de forma manual con su propia cookie si quería lugar de uso de las sesiones. @La Torre Todavía no puedo cambiar mi voto :(. De todos modos, ¿cómo abordar el problema de la falta de ‘REFERENCIA’?
    • que de hecho no no necesita una cookie para PUBLICAR fichas. Por ejemplo: 1) las visitas de los usuarios del sitio con ninguna de las cookies. 2) Usuario inicia sesión a través de CORREOS. 3) Sitio genera una página de tal forma que cada enlace incluye un token en ella, el almacenamiento de {token -> user_id} la persistencia de un mapa de 4) Usuario hace clic en un enlace, enviar el token. 5) Server quita el token después de la tramitación de la solicitud, continúe en el paso 3. Es inseguro para poner fichas en las peticiones GET, ya que el usuario podría, a continuación, copiar el enlace a una fuente externa; el usuario debe ser capaz de copiar lo que él quiere, no importa si es inseguro.
    • Ahh, me olvidaba de ese método. Pero sí, prefiero tener bastante url del modo de id de sesión o token CSRF en OBTENER los parámetros no son los ideales.

  2. 10

    Nada de eso – HTTP_REFERER puede ser libremente falso en el lado del cliente y no es un indicador fiable de donde una solicitud de vino.

    Actualización: que no entendí la parte acerca de la cruz del sitio falsificación: Para esto, comprobación de referer es válido medida de seguridad, porque CSRF dependen de manipular los enlaces que apuntan a páginas protegidas (que la atacó usuario tiene privilegios). Usuario @Torre es correcta.

    La única excepción es si el ataque puede ocurrir desde dentro de la aplicación web que está siendo atacado, por ejemplo, mediante la inyección de código JavaScript malicioso. En ese caso, una comprobación de referer es inútil ya que el ataque viene de un lugar «seguro» de la dirección URL, pero así es, posiblemente, una solución basada en una sesión o de un token de, porque el token está al alcance de la malicioso JavaScript y se puede recuperar fácilmente.

    Sin embargo, el uso de una sola vez token es altamente preferible para proteger contra este tipo de ataques porque HTTP_REFERER es despojado a cabo por algunos servidores proxy.

    • Estoy suponiendo que yo no quiero a alguien golpeando mi controlador de formulario desde otra url.
    • el modo más adecuado sería utilizar una sesión única o un token que se establece en el formulario, y se comprueba cuando el formulario. (Puede almacenar el token en una base de datos). De esa manera, usted puede al menos asegurarse de que la gente tiene que solicitar su formulario por primera vez (si es que realmente es de ayuda).
    • Impresionante respuestas. Gracias.
    • Cuando un adversario puede inyectar código javascript a ejecutar en el dominio real en lugar de solicitar de otro dominio, es XSS, no CSRF. La solución es simple, no permiten a las personas para inyectar código javascript en tu página.
    • uno de los puntos, tienes razón.
  3. 3

    Mediante una SESIÓN más probable es que sea la mejor ruta para evitar el cruce sitio de los envíos.

    • Estoy usando así. Estoy tan aterrado estoy mirando para agregar como muchos failsafes como sea posible.
    • Han considerado que el uso de algún tipo de captcha?
    • Que va a ser el nivel tres. Doy las gracias amablemente por sus respuestas.
    • Si vas hog wild igual que con varios niveles de seguridad, lanzando en un HTTP_REFERER corrector en la mezcla no me duele nada. Podría ser poco exagerado, pero si lo hace a usted o a su cliente a dormir mejor por la noche, que así sea, ¿verdad? Usarlo como una única línea de defensa no es la mejor opción.
    • Exactamente. Lo curioso es que esta vez que el cliente está en mí, y eso me hace más ansioso como es mi propia reputación en la línea. No quiero entrar en la escena social con huevo toda mi cara.
  4. 3

    Aunque es imposible parodia un Referer en otro navegador del usuario, es fácil para suplantar la falta de referencia (por ejemplo. el uso de un meta-refresh), además de algunos agentes de usuario no enviar un Referer en todo.

    Así que usted permitir que faltan-referente y no estancos XSRF de protección, o requieren un referente que coincida con su sitio, en el que caso de que usted tome un gran éxito para la accesibilidad. Que el golpe puede ser aceptable si la única persona que utiliza la secuencia de comandos es usted, y usted sabe que siempre va a ser el uso de un navegador/firewall/proxy/etc combinación que pasa a través de referentes de forma fiable. Pero para cualquier cosa que esperar a otras personas a utilizar, generalmente no es una buena idea.

    Referer es bastante débil anti-XSRF mecanismo. Es mucho mejor usar una por usuario/evento token emitido por el servidor, que debe llegar de vuelta al servidor para validar la presentación.

    $consulta = «SELECT * FROM users DONDE name = ‘$nombre'»;

    Potencial vulnerabilidad de inyección SQL. Por favor utilice mysql_real_escape_string o parametrizar las consultas.

    de entrada.setAttribute(‘nombre’, ‘add_bar’);

    de entrada.setAttribute(‘valor’, «);

    No uso setAttribute en los atributos de HTML. Hay errores en IE que dejar de trabajar en algunos de los casos, y hay algunos atributos que no hacen lo que usted piensa. Por ejemplo, la configuración de la value atributo es no la misma como la configuración de la value de la propiedad. La propiedad contiene el valor actual del campo de formulario; el atributo de sólo mantiene el ‘valor por defecto’ de campo, para lo cual se restablecerá si un <input type="reset"> se utiliza. Esto se asigna a la defaultValue de la propiedad. En algunos navegadores, ajuste el valor predeterminado también se establece el valor, pero esto no es estándar y no se debe confiar.

    Utilizar el DOM Nivel 1 propiedades HTML, son tanto más legible y más fiable:

    input.name= 'add_bar';
    input.value= <?php echo json_encode(generate_session_token(), JSON_HEX_TAG); ?>;

    Uso json_encode para crear valores para JavaScript literales. Aunque usted puede estar seguro de una suma-MD5 no contienen caracteres especiales a JS como ' o \, o la </ secuencia que termina un <script> bloque (en contra de que el HEX_TAG argumento de la protección), no es la salida de la plantilla de trabajo para saber lo que el token de sesión puede contener. Esta es una manera segura a la salida de cualquier cadena en un <script> bloque.

    Ver esta pregunta para una aproximación a la generación de anti-XSRF tokens que no requiere ningún extra token de almacenamiento en la sesión o de la base de datos.

    • Cabe señalar que la vulnerabilidad de XSS omite tanto basada en token de xsrf de protección así como una comprobación de referer. Te importa explicar como un enfoque es más débil que el otro?
  5. 2

    Sí, es seguro

    Por desgracia, la santo texto alienta para proporcionar una opción para deshabilitar el remitente (pero aún no se puede inventar su propio mecanismo de lo que un referente es); de hecho, alguien podría desactivar las url de referencia en su navegador, con lo que se impide a sí mismo el acceso a su sitio.

    Su solución es seguro, pero los usuarios pueden legítimamente se quejan si su sitio web sólo funciona con referentes habilitado.

    Esto es muy triste porque ahora significa que no hay sane manera de asegurarse de que su sitio no es seguro contra CSRF.

    Alternativa

    La única otra cosa que puedes hacer es poner un nonce en cada solicitud autenticada a su servicio de internet. Sin embargo, esto es algo peligroso porque usted tiene que asegurarse de que cada solicitud de momento en su web de servicio valida el nonce. Sin embargo, usted puede utilizar un framework para hacer esto para usted, para algo migitate esta molestia. Desbordamiento de pila en sí mismo parece ser el uso de nonces.

    Sin embargo

    Referentes en principio son un poco más seguro porque usted puede aplicar una regla global que dice que no solicitud puede tener lugar a menos que el remitente está en el mismo dominio. Esto es aceptable si usted está dispuesto a soltar a los usuarios que desactivar las url de referencia.

    Al contrario de lo absurdo que la gente está diciendo aquí, que no puede emitir una petición HTTP con un falso encabezado de los no-privilegiados navegador de código. Como era de esperar, Flash fue capaz de hacer esto una vez para eludir anti-csrf que se basa en referente, pero fue parcheado. ¿Por qué fue parcheado? Porque el RFC HTTP dicta lo que el referente es, por lo tanto, usted no podrá cambiar el sentido de que en su código de cliente, para que su cliente sea inseguro.

    Alguien aquí incluso afirmó que un applet de Java puede emitir arbitraria encabezados a través de HTTP a otro dominio, pero que simplemente no es el caso porque un espacio aislado applet de Java no está autorizado a hacer solicitudes para nada, excepto el dominio sobre el cual estaba cargado de. Él rápidamente se quitó su comentario antes de que alguien lo corrija…

    Caso en el punto

    Un navegador web es un cliente HTTP. Un cliente HTTP que debe cumplir los HTTP Rfc; por lo tanto tiene que cumplir con lo que el RFC de los estados de un remitente de cabecera debe ser similar. Desde un navegador web es un cliente HTTP, cualquier aplicación incrustado en un navegador web no debe ser capaz de hacer que las solicitudes que violan el protocolo HTTP. El hecho es que cada violación de una norma es un potencial agujero de seguridad.

    En cualquier caso: no hay forma adecuada para determinar si una solicitud es de su dominio o de un adversario del dominio. Este es sólo uno de los muchos tristes defectos de la web. Usted debe usar una de estas mencionadas soluciones.

    • ¡Qué tontería! Dices a ti mismo Flash was able to do this once to bypass anti-csrf that relies on referrer, but it was patched. Entonces, ¿qué acerca de las personas que están usando la versión no actualizada? Claramente hacer no entender lo que estamos diciendo. CUALQUIER SOLICITUD PUEDE SER FORJADO. El real paquetes TCP podría ser manipulado… ¿entonces qué?
    • NO. Flash es la corriente constante de la crítica de los fallos de seguridad. Y el resto de lo que usted dijo es irrelevante.
    • la falsificación problema es menos relevante que el hecho de que algunos servidores proxy (o loco configurar los navegadores) se tira todos los referidos, como BalusC señaló en un comentario en la pregunta. Así que si la demanda de un cierto referer, usted puede estar bloqueando a los usuarios legítimos así.
    • Usted no cree que algunas personas nunca actualización de su software? Qué sueño de la tierra viven en? En teoría es seguro, en la práctica, si es tan importante, a continuación, debe haber otros métodos para asegurar, a saber, el uso de un SESSION y un único auth_token en el formulario.
    • L, la mayoría de los navegadores están codificados en C, y tiene el ocasional pila de smash vulnerabilidad y si no, semántica vulnerabilidades. Usando de referencia es tan seguro como un auth token. Jeff es correcta, lo único malo que puede pasar es que el usuario se bloquea. Es igual de probable que un navegador para romper referencia las reglas de como es para que el navegador tiene alguna otra vulnerabilidad.
    • ¿Por qué fue esta votada abajo? Ninguna razón?

  6. -3

    De hecho, usted puede utilizar una dirección dinámica de esa forma. Como cuando el usuario vaya a su forma hacia él a una página con direcciones aleatorias, tales como http://www.something.com/form.php remitido a http://www.something.com/form.php?13mklasdkl34123 donde 13mklasdkl34123 se genera de forma aleatoria para cada usuario y almacenarlo en $_SESSION. Sobre la recepción del formulario de envío, usted puede consultar la referencia es la dirección que genera para el usuario. Referencia puede ser falso, sino una dinámica de referencia no como el spoofer no puede saber la dirección, a menos que él (de forma individual) visita la página de formulario.

    • NO. 1. Referencia sea puedan ser suplantados no es un problema aquí. El único problema acerca de los referentes de la solución es que se niega el servicio a algunos usuarios. 2. Su solución es errónea. Si lo haces de esta manera, usted DEBE generar un token nuevo para todos solicitud. Esto significa que cada vez que cargue una página, el servidor almacena un token correspondiente a tu id de sesión, y todos los enlaces emitida por el servidor tiene que token en ellos. Cuando se carga una página nueva, se repite el proceso. Que no utilizar el mismo símbolo (token) para cada solicitud, o puede ser propiedad de varias maneras, tales como capturas de pantalla y remisiones a otros sitios.
    • corrección a mi comentario anterior: en realidad, Hay maneras de utilizar un único token, pero este no es uno de ellos.

Kommentieren Sie den Artikel

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein

Pruebas en línea