Menú

Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menú

Mensajes - #!drvy

#741
Y si, tienes un problema de encoding en el ejemplo final. La estructura del HTML la tienes bastante mal, supongo que lo has creado con algun editor WYSWYG o algo por el estilo. Te recomendaria meter los estilos [<style>] y los meta [<meta>] dentro del <head> (estándar de programación). Además siempre es aconsejable meter el meta charset o señalar el tipo de encoding que se usa.

Código (html5) [Seleccionar]
<meta charset='UTF-8'>

Tampoco te aconsejo que centres el texto porque acaba cansando la lectura sobre todo en pantallas anchas. Creo que te vas a beneficiar mucho si adoptas markdown como formato para escribir tutoriales.


Por lo demás, el tutorial guay, aunque te recomendaria que uses ES6 pues ya estamos casi en 2020 y la gente quiere ver cosas con ES6 xD


Saludos
#742
Creo que no lo has entendido. Vamos plantear un sistema con pseudocódigo.

Planteamiento de la tabla:

user_id | name | password | online | last_active.

user y password guardarian lo que tu imaginas que guardan. online puede guardar un estado forzado de 0 o 1 según el usuario. last_active guardaría un timestamp de la ultima acción que ha realizado el usuario.

Ejemplo
1 | drvy | abcd123456abcd | 1 | 1571126689

Soy drvy, con id 1, tengo un hash muy raro, estoy conectado y mi última acción fue a las 10/15/2019 @ 8:04am (UTC).


Bien, ahora, cada vez que navegue a una página, o haga una acción cualquiera mientras este identificado como drvy, vas a actualizar el campo last_active por el timestamp actual.

Primer user case:
- Inicio sesión ->el sistema guarda timestamp y pone la columna "online" en 1.
--- Navegó a mi perfil -> el sistema guarda timestamp
------ Me cambio el correo -> el sistema guarda timestamp
--- Voy a la portada -> el sistema guarda timestamp
- Cierro la sesión -> el sistema guarda timestamp y pone la columna "online" en 0.

Segundo user case:
- Inicio sesión -> el sistema guarda timestamp y pone la columna "online" en 1.
--- Navegó a mi perfil -> el sistema guarda timestamp
------ Me cambio el correo -> el sistema guarda timestamp
--- Voy a la portada -> el sistema guarda timestamp
- Cierro la pestaña sin cerrar sesión.


Ahora, la función para comprobar si el usuario esta online:

bool isOnline (int user_id) {
   int grace_period = (time() - 1200);
   char query = 'SELECT user_id FROM users WHERE user_id = ' . user_id . ' AND (online = 1 AND last_active > ' . grace_period . ')';
   return (make_query(query) > 0 ? true : false);
}


Que hacemos. Establecemos un periodo de gracia de 20 minutos (1200 segundos que se restan al tiempo actual). Hacemos una query que dice: Dame todos los usuarios cuyo id es user_id y que: están marcados como que estan online y su ultima acción fue dentro del periodo de gracia y si la query retorna algún usuario (más de 0) es que el user_id está online. Así, si un usuario se sale sin cerrar la sesión, solo se le verá como online durante 20 minutos más o si sale de manera adecuada se le mostrará como offline de inmediato.

En el primer user case, desde que inicia sesión hasta que la cierra se le verá online e inmediatamente después se le verá como offline. En el segundo user case, se le verá online desde que inicia sesión hasta pasados 20 minutos de el cerrar la pestaña (y por lo tanto no realizar ninguna acción).

De hecho el sistema de este foro ni siquiera utiliza la columna online. Simplemente se basa en la cuando fue la última acción de usuario para considerarlo en linea o no.


Saludos
#743
PHP / Re: [Problema]: Sistema anti ataques (CSRF)
15 Octubre 2019, 09:46 AM
Igual estás ejecutando la función antes de la comprobación del token ende se genera un nuevo token antes de validar el antiguo. Si es el caso, yo  lo que suelo hacer es guardar el valor antiguo y el nuevo. Usas el antiguo para comparar y el nuevo para insertar en campos.

Un ejemplo así sin pensarlo mucho:

Código (php) [Seleccionar]
function createToken($name = 'token')
{
   $new_name = 'csrf_'.$name;
   $old_name = 'csrf_old_'.$name;

   if (!empty($_SESSION[$new_name])) {
       $_SESSION[$old_name] = $_SESSION[$new_name];
   }

   $rand = bin2hex(random_bytes(32));
   $_SESSION[$new_name] = $rand;
   return $rand;
}


function validateToken($name = 'token', $value = null)
{
   $old_name = 'csrf_old_'.$name;

   if (!empty($_SESSION[$old_name]) && $_SESSION[$old_name] === $value) {
       return true;
   }

   return false;
}



Código (php) [Seleccionar]
<?php
$csrf_token 
createToken('patata');


if (isset(
$_POST['csrf_token']) && validateToken('patata'$_POST['csrf_token'])) {
    echo 
'token valido';
}

?>



<form method='POST'>
   <input name='csrf_token' type='hidden' value='<?=$csrf_token?>'>
   <button type='submit'>Enviar</button>
</form>




PD: Comprueba siempre los strings con === (3 iguales) en vez de 2.
https://stackoverflow.com/questions/4732706/whats-the-difference-between-equal-and-identical-comparison-operators-in-php

PD2: echo NO es una función. No uses paréntesis () si no vas a hacer comprobaciones.
https://www.php.net/manual/es/function.echo.php
Nota: Puesto que esto es una construcción del lenguaje y no una función, no puede ser llamada usando funciones variables.


Saludos
#744
Si sabes hacer un login, imagino que sabrás hacer un registro y si sabes hacer un registro, ya entiendes la lógica que se sigue para guardar información del usuario en una base de datos o en un archivo y de ahí se asume que entiendes como guardar información que te proporciona el usuario y que dicho usuario pueda modificar dicha información.

Si no lo sabes, sugiero repases un tutorial de PHP y MySQL como ejemplo.

Saludos
#745
CitarLas paginas web hechas con CMSs, sobre todo las hechas con Wordpress, tienen fama de ser hackeables.

Tienen fama de ser los más atacados y por tanto donde más vulnerabilidades se suelen reportar. No son los más hackeableas en el sentido de que sean los más fáciles o algo así.

CitarEN primer lugar porque el CMS no restringe el acceso al codigo que lo compone (cualquiera puede descargarlo gratuitamente y acceder a su codigo, buscar errores, estudiarlo, etc)

El código libre es un arma de doble filo. Publicando el código fuente consigues que la gente encuentre errores y vulnerabilidades y que estas puedan ser solucionadas antes de tiempo o siquiera que puedan ser solucionadas... por otro lado, también abres la puerta a que la gente que encuentre problemas no los reporte.

Eso NO es un fallo de diseño ni nada parecido. No es malo publicar el código fuente, de hecho en muchas ocasiones es la única vía para proyectos que no se financian de forma regular y que son hechos a base de aportaciones de la comunidad.

Ocultar el código fuente no previene la vulnerabilidad si es que esa existe, solo la oculta. A esto se le llama seguridad por obscuridad y no se considera una buena practica.

https://es.wikipedia.org/wiki/Seguridad_por_oscuridad

CitarEn segundo lugar porque son tan famosos que resultan un blanco tentador para muchos.

Si, es cierto, creo que es el CMS más utilizado del mundo por lo tanto tiene sentido que sea el más atacado también.

CitarY en tercer lugar porque, mientras mas plantillas y plugins instalen los dueños de estos CMSs, mas accesos de hackeo abren en su pagina (llamemosles puertas, si quieren), pues, estas aplicaciones externas tienen codigo de diferentes personas, que uno ni sabe si es seguro o si esta compuesto correctamente.

Y si, es cierto también, cuanto más instalaes, más riesgo contraes.


Citar¿que tan cierto es que una pagina hecha con Wordpress u otro CMS es muy hackeable?

Probablemente es menos hackeable que una página hecha a mano. En Wordpress ya se ha pensado el sistema de login, el sistema de input, los permisos, las sesiones etc. No es comparable con ponerse a reinventar la rueda y rezar que lo que has hecho es "seguro". Es el problema de muchos programadores novatos, que se creen que si lo hacen ellos, es más seguro y luego ves el código y ni sanitizan, ni previenen CSRF ni previenen robo de sesiones ni nada.

Citar¿Si se lo propusieran ustedes, podrian hackear una pagina con Wordpress ahora mismo?

Las cosas no funcionan así. Tu no vas a un sitio con Wordpress, pulsas un botón y bum, juankeado. No. Puedes intentar acceder... si tiene vulnerabilidades, si expone más información de la necesaria, puedes intentar fuerza bruta etc.. pero no tienes garantias de que vayas a poder entrar ni asumes que lo vas a hacer.

Citar¿Una pagina que te brinda su codigo de composicion, es mas facil hackear que una que no lo hace?

Esto también es un concepto que muchos que acaban de entrar en el tema no entienden. Tu cuando ves el código fuente en un navegador, estas viendo solo lo que el sistema te quiere mostrar. Estas viendo lo que le hace falta a tu navegador para mostrarte la página. La lógica que hay detrás de todo como el login, el registro, el manejo de input y sesiones etc.. esta del lado del servidor y tu ese codigo no lo ves.

Y bueno, si te refieres a que si es más fácil hackear una CMS que tiene su código fuente libre, pues mirate lo de Seguridad por Obscuridad. El ejemplo más sencillo para contrarrestarlo es Windows donde el Microsoft no publica el código fuente pero aun así sigue siendo el sistema operativo más atacado y por lo tanto con más vulnerabilidades reportadas.


Citarque hackean a los que cometen errores de seguridad, pero si no los cometes no te pasa nada.... ¿entonces, quien tiene la razon?

No hay nada "inhackeable". Puedes tener buenas practicas de seguridad y que mañana Wordpress publique una actualización que introduzca una vulnerabilidad y que haya alguien que se dedique a joder.. si.. pero vamos, yo prefiero un sistema testeado mil veces antes que un sistema hecho a mano o por un don nadie donde no tienes en cuenta ni 10 de las 1000 variables y rutas de ataque que te pueden ejercer.

Las buenas practicas de seguridad como los permisos adecuados, las restricciónes de escritura en plugins, captchas en formularios, limite de intentos, borrado de sesiones, etc son necesarias y ayudan a prevenir, pero nada hace tu sistema "inhackeable".


Saludos
#746
Me imagino que es un script mal pensado (por fijar un año en vez de comprobar edad) que intentaba limitar la entrada a menores hace unos años pero que se ha quedado obsoleto. Si tienes más de 16 años, creo que no tienes ningún problema.

Saludos
#747
Es javascript, lanza una "alerta" que muestra de mensaje "test". Probablemente querían probar a ver si era vulnerable a XSS.

Saludos
#748
En Twitter se está hablando de que Siria ha pedido a Rusia y otros aliados establecer una zona de exclusión aérea en el norte con el fin de prevenir que bombarderos y cazas turcos apoyen a las fuerzas terrestres.  Algunos medios reportan que Rusia va a enviar cazas de interceptación. [1] [2] Tambien he leido de peticiones para que la zona sea establecida por Francia o por Estados Unidos. Por otro lado, el secretario de La liga Árabe ha clasificado las acciones de Turquía como una Invasión [3].

También se ha reportado que cientos de prisioneros de ISIS han escapado después de varios bombardeos de la aviación turca [4] [5] [6].


Lamentable que Europa le este lamiendo el culo terrorista de Erdogan su p**a mente retrograda. Más lamentable aún que el congreso de los Estados Unidos permita a la trumpeta que abandone a un aliado en favor de sus propios intereses (las torres Trump en Turquía). Asco.

Saludos
#749
Bugs y Exploits / Re: Dos y DDos
14 Octubre 2019, 07:02 AM
Citarel Dos es cuando abres el cmd y pones ping (ip/dominio) -t -l (numero del 1 al 65500) No?

Eso es un intento de DoS que lleva siglos siendo obsoleto y no funcional, pero si, es eso..


Citary sino diganme como se hace DDos

Este foro esta en contra de esta practica y solo fomenta la defensa contra dichos tipos de ataques. Aquí no se te va a enseñar a hacerlo.. para eso tienes Google.


Saludos
#750
Estas pidiendo un 0 day.


Saludos