¿Hay alguna diferencia entre GET y POST para la seguridad de la aplicación web?

La opción 1 puede introducir una serie de problemas no relacionados con la seguridad de todos modos:

• La URL resultante puede ser almacenada en caché por el navegador, o marcada, lo que hace que los usuarios vuelvan a enviarla.
• La URL resultante puede ser compartida por los usuarios, lo que hace que terceros la envíen.
• La URL se puede enviar a el proveedor de su navegador , que puede acceder al sitio .

Pero se trata de seguridad e introduce algunos riesgos que no están presentes en la opción 2:

• La URL con su parámetro puede terminar en los registros de proxy de todo el camino, revelando sus datos.
• Tu función de decodificación ahora es un vector de ataque adicional. (¿Maneja correctamente Unicode? ¿Tiene restricciones de longitud?)
• Puede sentirse tentado a pensar que su cadena codificada es de alguna manera segura, cuando solo es seguridad a través de la oscuridad (y no mucha oscuridad), o quizás más apropiadamente, teatro de seguridad .

Eso dicho sin embargo; de lo contrario, son en gran parte equivalentes en la seguridad que ofrecen . Ambos envían datos de texto sin formato en el encabezado HTTP, y base64 no es exactamente una ciencia de cohetes (y puede codificar en base64 su versión POST).

Ninguno ofrece ninguna protección significativa para sus datos.

Si es información que no quieres que el usuario vea; ¿Por qué lo envías al usuario para empezar? Considere la arquitectura que está utilizando y vea si hay una manera de simplemente eliminar el riesgo por completo al no manejar esa información en el lado del cliente.

Entonces, para responder a la pregunta: con respecto al envío de datos, ambos revelan la misma información a un atacante; Elija la opción que sea más apropiada para la situación ( esta publicación del blog de Treehouse puede ayudar con eso ), pero no debes confiar en ninguno de los dos métodos para proteger realmente cualquier cosa.

Es fácil realizar solicitudes GET entre sitios al incluir una etiqueta <img> simple en una página web. Por ejemplo, en una página de www.evilhacker.com , algunos Javascript producen una larga secuencia de etiquetas <img> con rutas elegidas por el atacante, todas apuntando a www.targetbank.com - y su navegador incluirá el banco Cookie en todas las solicitudes.

Esto solo significa que es mejor que no admita GET de solicitudes, lo que implica cualquier modificación en el sitio de destino. Como regla general, las solicitudes GET deben reservarse para operaciones para las cuales los ataques de repetición no son un problema, es decir, en la práctica, lea los accesos a datos estáticos solamente .

Use POST para enviar solicitudes que modifiquen datos en el servidor.

Por la especificación HTTP , las solicitudes GET (por ejemplo, los parámetros en la URL) solo deben usarse para las solicitudes para recuperar (de ahí el nombre GET) pero no modificar los datos. Las solicitudes POST (parámetros no visibles, pero aún sin cifrar en la solicitud HTTP) deben usarse siempre que la solicitud cree / actualice / modifique los datos que se almacenarán en la base de datos (que no sean registros estándar). Esto hace que sea ligeramente más difícil para que los atacantes realicen falsificaciones de solicitudes en sitios cruzados, así como menos probabilidades de enviar por duplicado o almacenar información secreta en el historial de su página web / registros del servidor web.

¿Es la variable pin un secreto?

Lo que estás haciendo en este momento parece que podría ser inseguro dependiendo del significado de la variable pin . ¿Es necesario que esto se mantenga en secreto ante posibles escuchas ilegales o podría la gente interceptar el pasador realizar algún tipo de ataque con él? Si es así, solo use HTTPS (para el cifrado de extremo a extremo en la capa de transporte) para cada solicitud con esta información secreta. El valor base-64 que usaste parecía ser 3000670269 (concedido, tuve que agregar dos signos iguales para que sea una codificación b64 adecuada).

¿Qué pasaría si un atacante intentara usar otros pines?

Digamos mi pin='300670269' , pero para probar su sistema envié MzAwMDY3MDI1OQ (para pin='3000670259' ). ¿Eso les permitiría entrar efectivamente en la cuenta de otro usuario? Si es así, como mínimo, debería hacer algo como tener una variable POST extra como checksum=SHA256(pin+secret_server_side_string) donde secret_server_side_string es una cadena aleatoria larga (por ejemplo, algo como de10RRORX50UAUhx0dDIxJnzXKBAs68yjdWVz8QQ - 40 random upper + lower + los caracteres de los números tienen lg (62) * 40 = 238 bits de entropía), y sus aplicaciones solo actúan en el pin si la suma de comprobación coincide con el pin. Su aplicación debe generar la suma de comprobación (sin revelar el secret_server_side_string al cliente). También debe tener cuidado de que su aplicación realice comparaciones de cadenas de tiempo constante al verificar la suma de comprobación con el pin, por lo que su aplicación no es vulnerable a los ataques de tiempo.

Hay un ataque interesante reciente que ha sido explotado para evadir las Reglas de Firewall de Aplicaciones Web conocidas como " Parámetro HTTP ataque de contaminación ". Te lo explicaré con un ejemplo como

POST /index.aspx?par=1&par=2 HTTP/1.1
User-Agent: Mozilla/5.0
Host: Host
Cookie: par=5; par=6
Content-Length: 19
par=3&par=4 

Para esta solicitud posterior, el comportamiento de la aplicación dependerá del desarrollador y de como para Java.

1. javax.servlet.ServletRequestInterface (Query String direct parsing)
2. java.lang.StringgetParameter (java.lang.Stringname) Devuelve el valor de un parámetro de solicitud como una Cadena, o nulo si el parámetro no existe
3. java.lang.String [] getParameterValues (java.lang.Stringname) Devuelve una matriz de String     Objetos que contienen todos los valores del parámetro de solicitud dado.     tiene, o nulo si el parámetro no existe.

Además de la respuesta de Bob, hay otra desventaja de seguridad al utilizar solicitudes GET con parámetros sensibles.

La URL, que incluye la información confidencial, se envía a servidores web de terceros que alojan los recursos a los que hace referencia la página HTML resultante.

Ejemplo:

Primera solicitud:

GET /someCode/pages/somePage.jsf?pin=MzAwMDY3MDI2OQ HTTP/1.0
Host: domain

Respuesta a esa solicitud:

HTTP/1.0 OK
Content-type: text/html

<img src="http://thirdparty/hello.jpg" />

El navegador web presenta el HTML y trata de obtener la imagen de la siguiente manera:

GET /hello.jpg HTTP/1.0
Host: thirdparty
Referer: http://domain/someCode/pages/somePage.jsf?pin=MzAwMDY3MDI2OQ

Esto puede ser especialmente un problema cuando el HTML procesado en la página está controlado por un atacante (hasta cierto punto, habiendo incluido un html en la lista blanca). Por ejemplo, un servicio de correo web que coloca la sesión en la URL permitiría a los atacantes enviar una imagen en el cuerpo HTML del correo electrónico que apunta al servidor / script web del atacante. Luego, el atacante debe seguir la URL en el encabezado Referer enviado por el navegador web de la víctima al renderizar la imagen. Este tipo de vulnerabilidad de hecho afectó al correo de Excite (estamos hablando del historial aquí :)) y algunos otros servicios de correo web en el pasado.

Otro factor de seguridad a tener en cuenta es que los registros de acceso del servidor web normalmente capturarán las URL solicitadas, incluidos los parámetros de la cadena de consulta. Si no desea que la cadena de consulta se registre, es posible que deba recurrir a una solicitud POST.

Por supuesto, hay factores no relacionados con la seguridad que se deben tener en cuenta al decidir entre las solicitudes GET y POST, como el comportamiento del navegador al recargar la página, o cuando la página se recupera mediante el botón Atrás del navegador.

Sí. se supone que debes usar "publicar" para insertar, actualizar, eliminar y "obtener" como parámetros de consulta

insert into table1 values postvalue1,postvalue2
select * from table1 where column1=getvalue1

parametrice ambos contra inyección de SQL (o escape), ya que el cliente puede enviar cualquier cosa sin importar qué código javascript o html escriba.