deskpro123
Zeta
Verificación en dos pasos activada
Verificado por Whatsapp
sisis con eso ya esta
Muchas gracias amigo, usare ese en todos mis scripts 🙂🙂🙂
Recomiendo a todos los que usan scripts propios aplicar eso aunque ya tengan seguridad :encouragement:
sisis con eso ya esta
SELECT email, passwd, login_id, full_name
FROM members
WHERE email = 'bob@example.com' AND passwd = 'hello123';
SELECT email, passwd, login_id, full_name\r\n FROM members\r\n WHERE email = \'bob@example.com\' AND passwd = \'hello123\';
eso no es un code de injection... pero si te salvas... SQL injection - Wikipedia, the free encyclopediaAmigo, he implementado tu codigo, me lo encuentro super.
Testee un supuesto codigo de SQL Inyecction que es este:
Insertar CODE, HTML o PHP:SELECT email, passwd, login_id, full_name FROM members WHERE email = 'bob@example.com' AND passwd = 'hello123';
Cuando lo pase por el POST y el GET que es un textarea y lo imprimi en php me sale asi:
Insertar CODE, HTML o PHP:SELECT email, passwd, login_id, full_name\r\n FROM members\r\n WHERE email = \'bob@example.com\' AND passwd = \'hello123\';
Ya esos "\" me salvan de que me hackeen?
Un saludo amigo y mil gracias.
Cuando usas solo numeros lo fuerzas... usando (int)$_GET['variable'] y listo... eso hace que sea numero siempre... sino (lo que hace el code es aseguras las GET y POST)
code noin.phpPHP:<?php include('noin.php'); $SEC = new secure(); $SEC->secureGlobals(); ?>
PHP:<?php class secure { function secureSuperGlobalGET(&$value, $key) { $_GET[$key] = htmlspecialchars(stripslashes($_GET[$key])); $_GET[$key] = str_ireplace("script", "blocked", $_GET[$key]); $_GET[$key] = mysql_real_escape_string($_GET[$key]); return $_GET[$key]; } function secureSuperGlobalPOST(&$value, $key) { $_POST[$key] = htmlspecialchars(stripslashes($_POST[$key])); $_POST[$key] = str_ireplace("script", "blocked", $_POST[$key]); $_POST[$key] = mysql_real_escape_string($_POST[$key]); return $_POST[$key]; } function secureGlobals() { array_walk($_GET, array($this, 'secureSuperGlobalGET')); array_walk($_POST, array($this, 'secureSuperGlobalPOST')); } } ?>
uso este code en mis sitios de wargames (retos hack para aprender a hackear) y 0 dramas! (desde hace muuuucho tiempo... 2004 tengo el sitio...)
foreach($_GET as $key => $val)
{
$_GET[$key] = $val;
if(banned_words($val)){//ACCION}
}
con eso estarias... si aun asi quieres asegurar mas, hay codigos de .htaccess para bloquear todo intento de hackeo (o la mayoria)... sino tmb con mod_sec en el server podes bloquear esos intentos...Amigo, super bueno el codigo y ahora quiero optimizarlo aun mas asi que vengo a pedirte un poco de ayuda :witless:
Hé creado una funcion php que verifica si cualquier string tiene palabras bloqueadas... Quisiera filtrar todos los GET y POST, entonces cualquier request global(Post get) que haga que sea revisado por la funcion de palabras bloqueadas, hacerlo manual me tomaria mas tiempo, quisiera hacerlo apartir de tu codigo, he probado algo como if(p_bloqueadas($SEC->secureGlobals())) pero no me ha funcionado, lo que quiero es guardar un registro de lo que se ha tratado de insertar en caso de que se halla enviado una palabra bloqueada para asi tener mas control.
Un saludo amigo y gracias de antemano 😛7:
- - - Actualizado - - -
[MENTION=9679]cicklow[/MENTION] , tratando y tratando logre verificar cada variable GET y POST globalmente, haciendo un foreach con el siguiente codigo:
PHP:foreach($_GET as $key => $val) { $_GET[$key] = $val; if(banned_words($val)){//ACCION} }
Pero aun me quedan dudas.. si sanitizo las variables de la siguiente manera "addslashes(mysql_real_escape_string(htmlentities($val)))", estoy mas seguro? Esta bien esa sintaxis?
Por otro lado, cuales son las palabras clave mas usadas para hackeos e inyecciones? O como se llama ese tipo de informacion? Asi puedo agregarlas a la lista.
Y un saludo amigo.
con eso estarias... si aun asi quieres asegurar mas, hay codigos de .htaccess para bloquear todo intento de hackeo (o la mayoria)... sino tmb con mod_sec en el server podes bloquear esos intentos...
https://secure.rivalhost.com/knowle...against-MySQL-injections-and-other-hacks.html
Cuando usas solo numeros lo fuerzas... usando (int)$_GET['variable'] y listo... eso hace que sea numero siempre... sino (lo que hace el code es aseguras las GET y POST)
code noin.phpPHP:<?php include('noin.php'); $SEC = new secure(); $SEC->secureGlobals(); ?>
PHP:<?php class secure { function secureSuperGlobalGET(&$value, $key) { $_GET[$key] = htmlspecialchars(stripslashes($_GET[$key])); $_GET[$key] = str_ireplace("script", "blocked", $_GET[$key]); $_GET[$key] = mysql_real_escape_string($_GET[$key]); return $_GET[$key]; } function secureSuperGlobalPOST(&$value, $key) { $_POST[$key] = htmlspecialchars(stripslashes($_POST[$key])); $_POST[$key] = str_ireplace("script", "blocked", $_POST[$key]); $_POST[$key] = mysql_real_escape_string($_POST[$key]); return $_POST[$key]; } function secureGlobals() { array_walk($_GET, array($this, 'secureSuperGlobalGET')); array_walk($_POST, array($this, 'secureSuperGlobalPOST')); } } ?>
uso este code en mis sitios de wargames (retos hack para aprender a hackear) y 0 dramas! (desde hace muuuucho tiempo... 2004 tengo el sitio...)
(string)preg_replace('/[^a-z0-9-]+/', '', trim($string))
(int)preg_replace('/\D/', '', $int)
¡Celebro este topic! 🙂
Ya cansan los comentarios del tipo "quiero usar POST y no GET para evitar hackeos, jajaja.
Con los código que te dieron aquí ya estarías bien. 🙂
Aun así, siempre que la petición realice un cambio en el servidor (y no sea una simple consulta) se debe usar POST y no GET, y no solo eso, se deben utilizar cookies con un CSRF Token. Si no, aunque te protejas de la SQL Injection pueden hacerte un ataque CSRF (a ti o a tus usuarios) que básicamente consiste en invocar acciones en el servidor por parte del usuario al que atacan sin su consentimiento. Ejemplo:
Un archivo php procesa la operación de enviar dinero de una cuenta a otra. Si se usa GET o se usa POST sin CSRF token un atacante puede crear una petición que envie la acción de enviar dinero desde la cuenta del usuario atacado a la suya y colocar un script para lanzar esa acción en una página web que más tarde tendrá que conseguir que vea la victima. Si la victima tiene una sesión abierta en el servidor comprometido y visita la web del atacante automáticamente le enviará la cantidad de dinero que se haya fijado en el script de ataque sin siquiera enterarse.
Esto sucede porque las peticiones GET se saltan la protección de cross-origin y las peticiones POST si se hacen desde un action de un formulario también (no por ajax, ahi salta el cross-origin).
Corrígeme si me equivoco, pero entonces si utilizo $_SERVER['PHP_SELF'] no hay manera de que hagan ataque CSRF, ya que el proceso de envìo de datos se realiza antes de que se carguen las cabeceras del sitio.
<?php
$_SESSION["token"] = md5(uniqid(mt_rand(), true));
?>
<input type="hidden" name="csrf" value="<?php echo $_SESSION["token"]; ?>">
if (isset($_POST["csrf"]) && $_POST["csrf"] == $_SESSION["token"]) {
executeWhateverActionInServer();
}
Quizás sea por desconocimiento pero no entiendo que quieres decir.
PHP_SELF te devuelve la ruta del script.php que se está ejecutando, ¿para qué querrías recuperar eso?
Lo que debes hacer para evitar un ataque CSRF es generar en el servidor un token aleatorio y guardarlo en algún sitio relacionado con el usuario (generalmente $_SESSION o una cookie). Luego ese código cada vez que renderices un formulario lo renuevas y lo pintas en el formulario como un hidden input. Al procesar la request POST del formulario compruebas el token de $_POST con de la cookie o $_SESSION y si coinciden no hay ataque, si son distintos hay ataque (y lo gestionas como creas conveniente).
Renderizando el hidden input en el formulario:
PHP:<?php $_SESSION["token"] = md5(uniqid(mt_rand(), true)); ?> <input type="hidden" name="csrf" value="<?php echo $_SESSION["token"]; ?>">
Validando si hay ataque o no:
PHP:if (isset($_POST["csrf"]) && $_POST["csrf"] == $_SESSION["token"]) { executeWhateverActionInServer(); }
Podria ser modificado pero al comparar los tokens en back-end y al no coincidir no se realiza ninguna acción. CSRF/XSRF son ataques para ejecutar una acción sin la autorización o conocimiento del usuario.Entiendo la idea, pero.. ¿el campo tipo hidden no podría ser modificado por un atacante mediante "clic derecho -> inspeccionar elemento?.
Podria ser modificado pero al comparar los tokens en back-end y al no coincidir no se realiza ninguna acción. CSRF/XSRF son ataques para ejecutar una acción sin la autorización o conocimiento del usuario.
Imagina que en tu app tienes un logout con esta url: /logout.php
Y a alguien se le ocurre comentar: <img src="http://forobeta.com/logout.php">
Al entrar donde este ese comentario directamente te cerraría sesión. Ahi entra el token, algo aleatorio, único por sesión, difícil de adivinar, si no coincide no hace nada.
Suerte 🙂
Gracias amigo, solo uso GET para numeros, debo usar el primero verdad?
Asimismo, limita el número de números que se pueden colocar, si crees que no se colocarán más de 10 números entonces no es necesario dejarlo libre para colocar 500, como medida extra.
Utilizamos cookies y tecnologías similares para los siguientes fines:
¿Aceptas las cookies y estas tecnologías?
Utilizamos cookies y tecnologías similares para los siguientes fines:
¿Aceptas las cookies y estas tecnologías?