Mensajes

Te hago un resumen, es una subida por el upload un upload tuyo y por tu upload subes la shell.

What the fuck?, quede peor que al leer el POST anterior. Además como va a realizarse el upload al servidor, si es por mi upload?, un poco ilógico.

No entendistes, a ver yo entro a la web y hay un upload que no permite php ni
modificar cabeceras entonces yo me codeo un upload en asp, y lo subo por el
upload que no te deja subir php, y por hay subo la shell, ya está comprobado en varias
webs, y funciona perfecto



Un saludito!

[PD:]

Ehh?. No entendí.
PD: El nombre supongo que sería TwoUpload

Sí sería ese nombre pero es para cambiar un poco 



Te hago un resumen, es una subida por el upload un upload tuyo y por tu upload
subes la shell.

[.php]

Buenas entré a una web, y me encontré con que el upload que tenía no permitia
la subida de archivos .php intenté cambiar las cabeceras con el
http live headers pero tampoco funcionaba, entonces se me ocurrió la idea
de hacer un segundo upload por medio del primero, con la cuestión de que con el primero
suba otro upload, que es el que me permitirá subir mi archivo .php (Lo cual es la shell).
Entonces me codee mi upload con posible subida de php.











Este es el upload original, el que no me dejaba subir mi shell por que tenia
protección contra los archivos .php









Este upload es el que yo me codee para subir mi shell (Permitiendo la subida de .php)



Como veo que algunos no os habeis enterado os hago un esquema de como quedaría.










Está claro que el upload nuestro debe estar creado en un lenguaje que permita la función
de subida por el upload original (Ya sea, perl, html, etc..) el upload.html no debe mandar un archivo .php por que si no, no serviria.



Un saludo comunidad, espero que os haya gustado, por que lo que quiero es innovar un poco sobre este tema.  :drinking:



Creador: SkillmaX

Post para todos los programadores webs, para la protección de su web a todas las inyecciones.





Evitar ataque SQL Injection:


Este error es el más común, es uno de los mas basicos pero unos de los mas
utilizados, yo he encontrado hasta webs del gobierno con este simple fallo.

El fallo es sencillisimo:

Código:

Código [Seleccionar] Expandir

SELECT * FROM



El fallo de este codigo es el "*" que por ese pego alguien puede aplastar tu web.


La solución sería cambiarlo por:

Código:

Código [Seleccionar] Expandir

SELECT loquesea FROM


Si quitamos la * y lo sustimos por un nombre mas concreto el bug quedaría corregido.







Evitar ataque HTML Injection:





Los ataques HTML injection se producen en la parte en el que el user tiene que escribir
(Buscadores, Formularios, Libros de visita). El fallo más común en los libros de visitas
(Un ejemplo) es "<h1>" cual esa es la principal pista de si tu web es vulnerable.
Un ejemplo sería "<h1> hola </h1>" que si es vulnerable al aceptar saldria las letras
mas grandes.

Para fixear este bug haremos lo siguiente:

Lo primero que haremos es coger cualquier cadena y transformarla o "encriptarla"
en entidades html

Por ejemplo: <h1> hola </h1> que quedaría asín -> &lt;holat&gt

Para eso utilizaremos el siguiente codigo


Código:
<?php
$Seguridad = htmlspatis($_REQUEST['Elcomentarioquesea']);
echo $Seguridad;
?>


Asin no se mostrarían las letras más grandes ya que quedan transformadas
en unas entidades html.




Evitar ataque LFI:




Local File Inclusion significa la inclusión de los archivos internos de una web, los archivos
vulnerables.


Código:
<?php
$_GET['proteccion'] = str_replace(array('.','/','\\'),'',$_GET['proteccion']);
?>



Lo que hariamos hacer seria usar la funcion de php "str_replace" para eliminar los codigos utiles.


"str_replace" sirve para filtrar lo que necesiten para evitar lo que quieran borrar.





Evitar ataque RFI:





El RFI como lo indica la sigla, es un error de programacion en una web que nos permite ejecutar un archivo que tengamos subido a una web (atacante) en otra web (victima) . Cosa que en webs no vulnerables esto no tendria porque darse.

Lo que se busca para ver si una web es vulnerables es una variable en la web que lo sea, luego de esa variante se colocaria el codigo malicioso (nuestra shell)


Para prevenir este tipo de ataques, es posible utilizar o bien el indicador "./" para advertir que el archivo debe encontrarse en el directorio actual u otro indicador tal como "includes/". Ejemplo:

Código:
<?

?>



De esta forma no podría utilizar la variable page para RFI.






Evitar ataque DDos:



Un ataque DDos es un ataque que manda muchas peticiones al servidor
web hasta que acaba cayendose.


Para solucionar este problema podemos poner un ANTI-DOS o un captcha.
El captcha es una imagen con un texto aleatorio que sirve para identificarse.



Evitar ataque Full Path Discloure:




Explotar esta vulnerabilidad no significa que podamos hacer grandes cosas, simplemente nos entregará información que podría ser utilizada para lo que uno estime conveniente.



Para corregirlo simplemente debemos agregar, a cada llamada de la función, la siguiente validación:



Código:
  1.
     if(function_exists('add_action')) {
  2.
     [...]
  3.
     }









Algunas partes han sido cogidas de google.


Un saludo, skillmax