Seguridad web: ¿eres parte del problema?

 

 

 

  • SmashingConf Nueva York 2024
  • Implemente rápidamente. Implementar inteligentemente

  • Índice
    1. Un informe interesante sobre seguridad web
    2. URI: la principal forma de atacar un servicio web
    3. Diferentes tipos de ataques. ¿Qué significan estas palabras?
      1. Inyección SQL
      2. Secuencias de comandos entre sitios (XSS)
      3. Recorrido de ruta
      4. Falsificación de solicitudes entre sitios
      5. Inclusión remota de archivos (RFI)
      6. Suplantación de identidad
      7. secuestro de clics
    4. Formas básicas de aumentar la seguridad web
      1. Mantenga el código actualizado
      2. No permanezca conectado y no incite a otros a hacerlo
      3. Utilice contraseñas inteligentes y atraiga a los usuarios a hacer lo mismo
    5. Qué hacer en su servidor
      1. Desactivar el listado de carpetas
      2. Endurece tu PHP
      3. Desactivar mensajes de error
      4. Comprobar automáticamente PHP en busca de problemas de seguridad
    6. Qué hacer con su código
      1. HTML

    Descargo de responsabilidad : Las cosas de las que hablaremos hoy en este artículo no te convertirán en un experto en seguridad, del mismo modo que comprar una navaja suiza no te convertirá en cerrajero o comprar un látigo no te convertirá en un domador de leones. El propósito aquí es crear conciencia y tal vez hacer que algunas de esas palabrerías sobre seguridad sean un poco más comprensibles para usted.

     

    La seguridad de los sitios web es un tema interesante y debería ser una prioridad para cualquiera que tenga una presencia en la Web bajo su control. La seguridad web ineficaz conduce a todas las cosas que nos hacen odiar la Web: spam, virus, robo de identidad, por nombrar algunos.

    El problema de la seguridad web es que, por importante que sea, también es muy compleja. Estoy bastante seguro de que algunos de los que leéis esto ya sois parte de una red de ordenadores atacados y que vuestros servidores están enviando mensajes de spam sin que vosotros lo sepas. Sus correos electrónicos y contraseñas han sido recopilados y revendidos a personas que creen que necesita un reloj nuevo, un producto de mejora masculina o una hipoteca barata. El hecho es que usted es parte del problema y no sabe qué hizo para causarlo.

    La razón es que a los expertos en seguridad no les gusta hablar demasiado en público sobre lo que hacen y dónde radican los problemas; y, lamentablemente, también pueden parecer arrogantes en sus puntos de vista. Esto podría ser el resultado de que las personas no se toman en serio la seguridad y no siguen los consejos más básicos, como usar contraseñas inteligentes, no “contraseña” o “déjame entrar”.

    Otra razón son esos tutoriales que le muestran cómo “hacer algo en cinco minutos” y convenientemente omiten mencionar las implicaciones de seguridad de sus consejos. Si parece demasiado fácil para ser verdad, probablemente lo sea. Un ejemplo perfecto de esto son las soluciones PHP que utilizan un archivo para el almacenamiento de datos y le piden que pueda escribirlo en todo el mundo. Esto es fácil de implementar, pero significa que cualquier spammer puede escribir en este archivo.

    Un informe interesante sobre seguridad web

    La empresa de seguridad web Cenzic publicó un informe que detalla las tendencias y cifras relacionadas con la seguridad web para el primer y segundo trimestre de 2009, y las cifras son reveladoras:

    Entre las vulnerabilidades más graves se encuentran el recorrido de ruta, las secuencias de comandos entre sitios, la falsificación de solicitudes entre sitios y la inyección SQL. No se mencionan una amenaza más nueva, el clickjacking y un problema de interfaz de usuario llamado phishing. Es posible que tengas que lidiar con todos estos como desarrollador web si tocas PHP y HTML, CSS y JavaScript. Incluso si no usas PHP, aún podrías causar muchos problemas. Incluso si no tocas el código y simplemente diseñas, podrías ser un gran activo en esta área. Usted podría ayudar a que la Web sea más segura haciendo que los problemas de seguridad sean comprensibles para sus usuarios.

     

    Repasemos todas estas cosas y expliquemos qué son y qué hacen. Sin embargo, lo primero que necesita saber es cómo funcionan los URI.

    URI: la principal forma de atacar un servicio web

    La dirección de cualquier documento (es decir, un archivo en Internet) es su Identificador uniforme de recursos (URI). Esto es lo que ingresa en la barra del navegador para acceder al documento y lo que inserta en el código para señalar el documento. Por ejemplo, la dirección de mi sitio web es https://icant.co.uky el documento que ve cuando lo abre en un navegador es https://icant.co.uk/index.php(el servidor redirige automáticamente a ese documento). La imagen del logotipo reside en el URI https://icant.co.uk/iconslogo.png, y la imagen mía apuntándote a ti está en un servidor totalmente diferente y tiene el URI https://farm4.static.flickr.com/3172/3041842192_5b51468648.jpg.

    Puede acceder a todos estos URI. Sin embargo, algunos URI contienen información a la que no debería ser accesible para el mundo exterior. Por ejemplo, la /etc/passwordcarpeta de un servidor contiene contraseña e información de usuario que no debería filtrarse a Internet.

    Cada URI también puede contener parámetros. Estas son instrucciones que puede enviar al script ubicado en ese URI y que se agregan al URI comenzando con a ?y separados por símbolos. Si quieres buscar cachorros en Google, por ejemplo, puedes usar el URI https://www.google.com/search?q=puppies, y si quieres comenzar tu búsqueda después de los primeros 50 resultados, puedes usar https://www.google.com/search?q=puppiesstart=50.

    Normalmente, estos parámetros no los ingresan los usuarios finales sino que provienen de la interfaz HTML. Si miras el código fuente de la página de inicio de Google y te deshaces de las partes dolorosas, terminarás con el siguiente formulario:

    form name="f" action="/search" input type="hidden" value="en" name="hl"/ input type="hidden" value="hp" name="source"/ input name="q"/ input type="submit" name="push_button redG"/ input type="submit" name="push_button redI"/ input type="hidden" name="aq"/ input type="hidden" name="oq"/ input type="hidden" name="aqi"//form

    En esencia, este formulario envía el contenido de todos estos campos al URI searchy los agrega a ese URI. Así es como terminas con esto

    https://www.google.com/search?hl=ensource=hpq=puppiesaq=foq=aqi=

    cuando envía el formulario. Observe, por ejemplo, que no tengo ningún btnGparámetro porque utilicé la tecla Intro para enviar el formulario.

    En la página de resultados de búsqueda, puede ver los enlaces de paginación en la parte inferior (el 1 2 3 y así sucesivamente debajo del logotipo de Gooooooogle ), y puede ver que estos enlaces envían los mismos datos al URI y agregan un startparámetro:

     

    a href="/search?hl=enamp;q=puppiesamp;start=40amp;sa=N"5/a

    Puede enviar parámetros a un script con el URI a través de campos de formulario, enlaces o cualquier otra cosa en HTML que contenga un URI: imágenes, elementos de enlace, marcos, cualquier cosa que pueda tomar un atributo hrefo src. Si un atacante puede anular cualquiera de estos o agregar una nueva imagen a su HTML sin que usted lo sepa, podría apuntar a sus propios URI y enviar sus propios parámetros.

    Debe tener cuidado con lo que contienen sus parámetros y hacia dónde apuntan, que podría ser el servidor de otra persona (para obtener más código) o secciones de su propio servidor que no desea mostrar o enviar a otro servidor.

    Diferentes tipos de ataques. ¿Qué significan estas palabras?

    Repasemos rápidamente los diferentes elementos mencionados en el gráfico anterior, explicando qué son y qué significan.

    Inyección SQL

    Con una inyección SQL, un atacante accede a su base de datos enviando un comando SQL a su servidor a través del URI o los campos del formulario. Esto se soluciona fácilmente desinfectando , pero no hacerlo puede ser fatal para tu sitio web, como muestra el siguiente cómic de XKCD :

    Secuencias de comandos entre sitios (XSS)

    Las secuencias de comandos entre sitios son probablemente el problema más grande y común. Con él, un atacante inyecta código JavaScript en su documento agregándolo al final del URI como parámetro o en un campo de formulario.

    Supongamos que quiere ser atractivo y permitir que los visitantes personalicen ciertos colores en su página. Podrías hacer esto fácilmente en PHP:

    ?php // predefine colors to use $color = ’white’; $background = ’black’; // if there is a parameter called color, use that one if(isset($_GET[’color’])){ $color = $_GET[’color’]; } // if there is a parameter called background, use that one if(isset($_GET[’background’])){ $background = $_GET[’background’]; }?style type="text/css" media="screen" #intro{ /* color is set by PHP */ color:?php echo $color;?; /* background is set by PHP */ background:?php echo $background;?; font-family:helvetica,arial,sans-serif; font-size:200%; padding:10px; }/stylepCool intro block, customizable, too!/p

    Hasta ahora, todo es kosher y ¡ni siquiera usamos estilos en línea! Si guarda esto ahora como test.php y lo llama en su servidor en su navegador como URI https://example.com/test.php, obtendrá un bloque de introducción de texto negro sobre blanco. Las $_GET[]variables provienen del URI como parámetros y, como no están configuradas, nada cambia. Si quieres que los colores sean rojo sobre rosa, puedes hacer esto: https://example.com/test.php?color=redbackground=pink.

    Pero como se permite cualquier valor para las variables, un atacante podría enviar lo siguiente:

    https://example.com/test.php?color=greenbackground=/stylescriptalert(String.fromCharCode(88,83,83))/script

    Esto cerraría efectivamente el bloque de estilo prematuramente y agregaría un script al documento. En este caso, todo lo que haríamos sería escribir la palabra XSS, pero podríamos hacer cualquier cosa que JavaScript pueda hacer. Puedes ver los resultados en la siguiente captura de pantalla:

     

    Una vez que haya inyectado JavaScript con éxito, podrá leer las cookies; formularios abiertos que solicitan al usuario que introduzca sus contraseñas o datos de su tarjeta de crédito; ejecutar virus, gusanos y “descargas no autorizadas”; la parcela. La razón es que JavaScript no está sujeto a ningún modelo de seguridad; cualquier script en la página tiene los mismos derechos, sin importar de qué servidor provenga. Este es un gran problema de seguridad con JavaScript y es algo en lo que están trabajando personas inteligentes.

    XSS es un problema muy común. Los sitios web como XSSED.org se divierten mostrando al mundo cuántos sitios web son vulnerables:

    El remedio para XSS es estar muy paranoico con cualquier cosa que llegue a través de formularios o URI. También debe asegurarse de que su PHP esté configurado correctamente (volveremos a algunas formas de probarlo y escribir un buen código más adelante).

    Recorrido de ruta

    Permitir el recorrido de rutas o directorios en su servidor es una idea sorprendentemente mala. Estaría permitiendo que las personas enumeren las carpetas en su servidor y naveguen de una carpeta a otra. Esto permite a los atacantes ir a carpetas con información confidencial o funcionalidad del sitio web y divertirse. La siguiente captura de pantalla me muestra accediendo a la base de datos de una empresa de sándwiches, enviando correos electrónicos desde su servidor y leyendo los registros de pedidos:

    Pude obtener toda esta información simplemente accediendo a la carpeta cgi-bin , que no estaba protegida para no aparecer en la lista. Entonces, en lugar de ir a https://example.com, fui a https://example.com/cgi-bin/mi navegador. Supe que algo andaba mal en su gran sitio web Flash cuando hice clic en el menú. Apareció en una nueva ventana y tenía un URI como

    https://www.example.com/cgi/food_db/db.cgi?db=defaultuid=defaultCategory=SandwichesSubcategory=SandwichesProduct=Chicken%20and%20BaconSoup_size=Drinks_milk_type=ww=onview_records=yes

    lo que me dio toda la información que necesitaba para jugar.

    El otro problema de permitir que se incluyan carpetas en la lista es que los motores de búsqueda indexarán su información, lo que permitirá que cualquiera pueda utilizar Google como herramienta de piratería. A medida que los servidores crean una página con un título y un encabezado del nombre de la carpeta, Google los indexa.

    Puede buscar, por ejemplo, “índice de /ebooks” para encontrar libros electrónicos en línea o “índice de /fotos” para buscar fotografías.

    Por cierto, este método de búsqueda funcionaba mucho mejor en el pasado: no porque ahora la gente proteja mejor sus servidores, sino porque los spammers que ofrecen productos pirateados falsos se dan cuenta de que la gente hace estas búsquedas y las falsifica ahora para optimizar el motor de búsqueda de sus propios sitios web. clasificaciones.

    Falsificación de solicitudes entre sitios

    La falsificación de solicitudes entre sitios (CSRF) explota navegadores y sitios web que permiten llamar a funciones sin saber realmente que un usuario real la inició. Supongamos que tiene un formulario en su sitio web https://example.comque funciona con GET y envía elementos a su base de datos:

     

    form method="get" action="add_to_db.php" div label for="name"Name/label input type="text" name="name" /div div label for="email"email/label input type="text" name="email" /div div label for="comment"Comment/label textarea name="comment"/textarea /div divinput type="submit" value="tell me more"/div/form

    Los formularios se pueden enviar mediante dos métodos: GET agrega todos los parámetros al URI visiblemente en la barra de direcciones, mientras que POST los envía "debajo del capó". POST también te permite enviar muchos más datos. Esto es una simplificación pero es todo lo que necesitas saber por ahora. Serviços de finanças

    Si el script que agrega a la base de datos no verifica que el formulario realmente fue enviado desde su servidor, podría agregar una imagen a cualquier sitio web haciendo esto:

    img src="https://example.com/add_to_db.php?nombre=barato%[email protected]=mortgage%20help" ancho="1" alto="1"

    Cualquiera que visite mi sitio web estará poniendo otro comentario en su base de datos. Podría usar una imagen, un enlace CSS o un script o cualquier cosa que permita que un navegador defina y cargue un URI cuando se procesa el HTML. En CSS, esto podría ser una imagen de fondo.

    CSRF se vuelve aún más peligroso cuando inicia sesión y es autenticado por un sistema en particular. Una imagen en cualquier otra pestaña de su navegador podría ejecutar una transferencia de dinero, leer sus correos electrónicos y enviarlos y muchas otras cosas malvadas.

    Un caso realmente interesante de CSRF (aunque inocente) ocurrió en 2006, cuando Google lanzó su ahora descontinuada herramienta de aceleración web (GWA). La idea era buscar previamente los sitios web vinculados desde el documento actual, agilizando así la navegación. Todo muy bien... hasta que terminaste con enlaces de eliminación en sitios web que funcionaban así:

    a href="/app/delete_entry.php?id=12"delete/a

    Debido a que algunas aplicaciones no verificaron si se trataba de una eliminación iniciada o de un intento de GWA de precargar la página, la herramienta eliminó blogs completos y bases de datos de productos. Google no hizo nada malo, pero la comunidad aprendió mucho sobre CSRF ese día.

    Ahora bien, podrías suponer que mover tus formularios de GET a POST los haría seguros, ¿verdad? Parcialmente, sí, pero un atacante aún podría usar un formulario y engañar a las personas para que hagan clic en un botón para realizar la solicitud:

    form method="post" action="add_to_db.php" div input type="hidden" name="name" value="bob" input type="hidden" name="email" value="[email protected]" input type="hidden" name="comment" value="awesome article, buy cialis now!" input type="submit" value="see beautiful kittens now!" /div/form

    Incluso podría usar JavaScript para enviar automáticamente el formulario o un script en otro servidor para realizar la solicitud POST desde el back-end. Hay muchas formas de explotar CSRF y protegerse contra él no es tan difícil.

    Inclusión remota de archivos (RFI)

    Con la inclusión remota de archivos o la inyección de código , un atacante utiliza una falla en su sitio web para inyectar código desde otro servidor para ejecutarlo en el suyo. Pertenece a la misma familia que XSS pero es mucho más problemático porque tienes acceso completo a tu servidor (con JavaScript, puedes robar cookies y llamar a otro código, pero no puedes acceder al sistema de archivos sin recurrir a trucos con Flash o Java). Applets).

     

    Cualquier código inyectado en su servidor con una variable y include()un comando no probados, por ejemplo, podría ejecutar comandos del servidor: cargar, descargar y transferir datos a otros servidores, verificar las contraseñas y nombres de usuario de su servidor, cualquier cosa que pueda hacer en la línea de comando a través de PHP o ASP si su servidor lo permite.

    Esto es probablemente lo peor que le puede pasar a su servidor, porque con acceso a la línea de comandos, podría convertirlo en una máquina de ataque para un ataque a la red del servidor, escuchar silenciosamente todo lo que usted y sus usuarios hacen en el servidor y enviarlo a otra Web. recursos, almacenar información y virus para su distribución, inyectar enlaces de spam, lo que sea.

    La solución es desactivar globalsy nunca ensamblar un URI a partir de parámetros o datos de formulario. (Más sobre esto más adelante en la sección PHP de consejos).

    Suplantación de identidad

    El phishing es la técnica de engañar a las personas para que ingresen información en un sitio web incorrecto. Muestra a los usuarios finales una interfaz que parece legítima (para un banco o lo que sea) pero que en realidad envía su información a su base de datos. Debido a que el phishing es un delito grave, no puedo mostrarle una demostración.

    El truco del phishing es hacer que el formulario realmente parezca que proviene de un sitio web de confianza. Probablemente haya recibido correos electrónicos que le dicen que su “cuenta bancaria XYZ” se ha visto comprometida y sabe con certeza que este no es el caso porque no tiene ninguna cuenta en ese banco y es posible que ni siquiera haya oído hablar de él. Se trata de un intento de phishing descabellado, que normalmente no resulta eficaz.

    Sin embargo, en la Web, un atacante puede realizar un truco de JavaScript para descubrir dónde ha estado. Como demostró Jeremiah Grossman hace algunos años , puedes usar JavaScript para determinar el estado de un enlace en la página. Debido a que los colores de los enlaces visitados y no visitados son diferentes, podemos utilizar esta técnica para determinar qué sitios web ha visitado un usuario y luego mostrar el logotipo apropiado encima del formulario. Esta demostración muestra esto de manera bastante efectiva .

    secuestro de clics

    Clickjacking es una forma terriblemente inteligente de usar CSS y marcos en línea para engañar a los usuarios para que hagan clic en algo sin saberlo. Probablemente el ejemplo más famoso de esto fue el exploit "No hagas clic en mí" de Twitter hace unos meses. De repente, Twitter se llenó de mensajes que apuntaban a un sitio web con un botón que decía “No hagas clic en mí”. A continuación se muestran ejemplos de la transmisión de Jason Kottke:

    Siendo la naturaleza humana lo que es, muchas personas hicieron clic en el botón, lo que aparentemente no hizo nada. Sin embargo, lo que realmente hizo fue colocar su página de inicio de Twitter encima del botón como un marco, con una opacidad de 0 en el CSS. El campo de actualización estaba preestablecido con el tweet apuntando a la página. La siguiente captura de pantalla lo hace obvio, con la opacidad establecida aquí en 0,5:

     

    Al hacer clickjacking, puedes hacer que los usuarios finales hagan cosas sin saberlo. Cada acción en un sitio web que se puede realizar con un simple clic se puede explotar con este truco.

    El clickjacking es un problema enorme porque se realiza mediante CSS, no un script. A menos que los navegadores impidan que los marcos tengan una opacidad de 0, no existe una solución sencilla. La principal contramedida que toman las personas es no permitir la incrustación de marcos usando JavaScript. Sin embargo, con JavaScript desactivado, el clickjacking sigue funcionando.

    Formas básicas de aumentar la seguridad web

    Ahora que sabes un poco sobre lo que los malos pueden hacerle a tu sitio web, aquí tienes algunas formas de combatirlos.

    Mantenga el código actualizado

    No hay mejor protección que mantener tu código actualizado. Versiones obsoletas de WordPress, instalaciones antiguas de PHP y MySQL, incluso navegadores antiguos, todos estos son problemas de seguridad porque la mayoría de las actualizaciones de software en estos días son parches de seguridad. Es una carrera de ratas entre quienes quieren que la Web funcione y quienes quieren abusar de ella para ganar dinero rápido o robar su identidad. Así que ayude a los buenos actualizando cada vez que salga una nueva versión.

    No permanezca conectado y no incite a otros a hacerlo

    Permanecer conectado mientras no se utiliza un sistema es peligroso. Otros sitios web por los que navega pueden comprobar que ha iniciado sesión y luego hacer clic en usted para obligarlo a hacer algo que no es su intención o que no conoce. Esto es especialmente peligroso en las redes sociales porque todo lo que hagas se enviará a todos tus amigos y probablemente ellos lo replicarán. Es un efecto bola de nieve.

    En mi mundo perfecto, ningún formulario tiene la opción "Mantenerme conectado", lo que por supuesto sería una molestia para los usuarios finales. Me encantaría ver una solución inteligente y utilizable para este problema. Utilizo un cliente Flex para Twitter, no un navegador, lo que significa que no soy vulnerable ni siquiera en sitios web con clickjacking y falsificación de solicitudes entre sitios (esto último sólo si las personas no abusan de la API para realizar phishing a mis seguidores; vea las presentaciones en el al final de este artículo para una demostración de eso).

    Utilice contraseñas inteligentes y atraiga a los usuarios a hacer lo mismo

    Incluso en sistemas a prueba de balas, un vector de ataque son los usuarios cuyas contraseñas son muy fáciles de adivinar. Cambio mis contraseñas cada pocas semanas y me inspiro en un libro que estoy leyendo o en una película que acabo de ver. También reemplazo algunos caracteres y números para dificultar los ataques de diccionario.

    Hay dos formas de descifrar una contraseña (aparte de la ingeniería social, que consiste en hacer que me digas tu contraseña mediante engaño o phishing): fuerza bruta y ataques de diccionario. La fuerza bruta implica escribir un bucle que prueba todas las diferentes opciones (muy parecido a jugar al ahorcado), lo que puede llevar mucho tiempo y utiliza mucha potencia informática. Los ataques de diccionario utilizan una base de datos de diccionario para intentar palabras comunes en lugar de ir letra por letra.

     

    Digamos que estoy leyendo un libro de Sherlock Holmes o acabo de ver la nueva adaptación cinematográfica, mi contraseña podría ser Sh3rl0ckW4t50no b4sk3rv!ll3. Esto puede resultar un poco complicado para la mayoría de las personas, pero en general es una buena idea. Otra estrategia es tomar una frase que puedas memorizar fácilmente y unir las letras iniciales. Por ejemplo, “me gusta comprarle comida a mi perro y pasear con él” sería Il2bffmda2wwio incluso Il2bffmd2wwi.

    Por lo tanto, si crea un nuevo producto web que necesita autenticación y realmente necesita crear su propio sistema de inicio de sesión en lugar de utilizar Google, Yahoo, Facebook Connect u OpenID (lo cual podría ser una buena idea), no permita que los usuarios utilizar contraseñas como “contraseña” o “contraseña1”, que no es mucho más segura. Recientemente, se filtró en la Web una lista de contraseñas prohibidas por Twitter . Esta es una buena idea (es decir, la lista, no la filtración).

    Qué hacer en su servidor

    Incluso si no eres un experto en servidores, eso no es excusa para ejecutar un servidor inseguro. Aquí hay algunas cosas de las que debe asegurarse.

    Desactivar el listado de carpetas

    Como se explicó anteriormente, permitir que las personas naveguen por sus carpetas (es decir, recorrer rutas) es una mala idea. Probar si su servidor tiene activado el recorrido de ruta es fácil:

    1. Cree una nueva carpeta en el servidor; por ejemplo, prueba de ruta .
    2. Agregue algunos archivos a la carpeta. Pero no agregue index.html , index.php , default.aspx o cualquier otra cosa que su servidor use como nombre de archivo predeterminado.
    3. Verifique la carpeta en su navegador; por ejemplo, yendo ahttps://example.com/pathtest/
    4. Si puede ver una lista, comuníquese con el administrador de su servidor para desactivarla.

    Endurece tu PHP

    Si tienes un servidor con PHP, ten en cuenta que estás en control de una poderosa herramienta. El peor descuido que alguien podría cometer es permitir que cualquier parámetro que provenga del URI se convierta en una variable global. Esto está desactivado de forma predeterminada en instalaciones de PHP en la versión 4.2.0 y posteriores, pero es posible que su configuración haya cambiado. De hecho, algunos tutoriales recomiendan activarlo para que funcione un script: es una muy, muy mala idea.

    Puede probar fácilmente si los globales están habilitados:

    1. Crea un nuevo archivo llamado test.php .
    2. Agregue el siguiente código:

      ?php echo "*".$ouch.’*’;?
    3. Sube el archivo a tu servidor.

    4. Busque el archivo y envíe un parámetro llamado ouch; Por ejemplo:https://example.com/test.php?ouch=that+hurts

    5. Si su navegador muestra " eso duele ", entonces su servidor tiene datos globales registrados.

    6. ¡Comuníquese con el administrador de su servidor para solucionar este problema!

       

    ¿Porque es esto importante? Bueno, en nuestra explicación anterior de XSS, hablamos de que los atacantes pueden agregar código a su página usando los parámetros URI en su script. Si no desactiva los globales, cualquier variable que utilice y escriba podría convertirse en un ataque. Peor aún, considere el siguiente código:

    if($_POST[’username’] == ’muppet’ $_POST[’password’] == ’password1’) { $authenticated = true;}if($authenticated) { // do something only admins are allowed to do}

    Si esto es checkuser.php y el registro global está activado, entonces un atacante podría llamar a esto en el navegador https://example.com/checkuser.php?authenticated=truey podría evitar la verificación completa del usuario; su autenticación se $_GET[’authenticated’]convierte automáticamente en $authenticated.

    Desactivar mensajes de error

    Muchos servidores están configurados para mostrarle mensajes de error cuando el navegador encuentra un problema. Estos mensajes suelen parecer crípticos, pero son una gran fuente de información para los atacantes.

    Crear un error y ver lo que escupe el servidor es uno de los primeros pasos para verificar la estructura de carpetas de un servidor. Curiosamente, las páginas de error que decían "No se pudo encontrar el archivo XYZ" fueron una de las primeras oportunidades de ataque XSS, porque se podía buscar un archivo llamado scriptalert(document.cookie),/script.

    Comprobar automáticamente PHP en busca de problemas de seguridad

    Cargar PHPSecInfo a una carpeta es una forma bastante útil de realizar una auditoría rápida de la seguridad de su servidor PHP. Al abrirlo en su navegador, obtendrá una lista de verificación detallada de fallas de seguridad comunes y cómo deben solucionarse.

    ¡Pero nunca dejes esto en un servidor activo porque les brinda a los atacantes muchos detalles sobre tu configuración!

    PHPSecInfo le brinda información de seguridad detallada sobre su configuración de PHP.

    Qué hacer con su código

    Debido a que probablemente no tenga mucho que ver con su servidor, centrémonos en las cosas sobre las que tiene control total.

    HTML

    HTML es bastante seguro. Simplemente se convierte en texto, sin interacción con el servidor ni cálculos, por lo que no hay muchas cosas que puedan salir mal. Dicho esto, siempre debes usar HTML para lo que sirve:

    • HTML estructura tu contenido. HTML no es una base de datos para almacenar información. La razón por la que no es así es porque no se puede confiar en que el contenido HTML permanezca sin cambios. Cualquiera podría utilizar herramientas de depuración del navegador para modificar su HTML y cambiar el contenido. Por lo tanto, se encuentra con problemas de seguridad con las soluciones de JavaScript que se basan en datos en HTML y no verifican en el servidor cuáles son los datos permitidos.
    • HTML es completamente visible. No utilice comentarios en HTML para almacenar información confidencial y no comente secciones de una página que aún no estén listas pero que apunten a partes de una aplicación que están en progreso.
    • Ocultar cosas no hace que desaparezcan. Incluso si oculta información con CSS o JavaScript, algunas personas pueden obtenerla de todos modos. HTML





      Tal vez te puede interesar:

      1. ¿Deberían abrirse los enlaces en ventanas nuevas?
      2. 24 excelentes tutoriales de AJAX
      3. 70 técnicas nuevas y útiles de AJAX y JavaScript
      4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Seguridad web: ¿eres parte del problema?

    Seguridad web: ¿eres parte del problema?

    SmashingConf Nueva York 2024 Implemente rápidamente. Implementar inteligentemente Índice Un informe inte

    programar

    es

    https://aprendeprogramando.es/static/images/programar-seguridad-web-eres-parte-del-problemaja-767-0.jpg

    2024-05-20

     

    Seguridad web: ¿eres parte del problema?
    Seguridad web: ¿eres parte del problema?

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20