¿Puede alguien editar el file javascript fuera de línea para ejecutar código malicioso?

Estoy preocupado por algo relacionado con los files javascript de mi website, no estoy seguro si esto es factible.

Los files Js se downloadán cuando alguien visite un website, y si alguien editó el script js descargado e insertó su propio código, luego actualizó el website. En la nueva actualización, el website leerá el file editado Js y ejecutará el código malicioso. El código malicioso podría usarse para ejecutar código en el server de manera normal.

Ejemplo:

Un usuario solo puede publicar un artículo en su página:

HTML

El formulario del artículo solo se mostrará al usuario en su página.

<?php if( $user->id == $page->userID ) { ?> <form> <h1>Add new article:</h1><br /> <textarea name="articleText" cols="65" rows="3"></textarea> <input class="SubmitArticle" id="<?php echo $userPage->id; ?>" name="SubmitArticle" type="button" value="Submit article" /> </form> <?php } ?> 

Javascript

 $(".SubmitArticle").click( function(e){ var targetPage = $(this).attr('id'); var thisForm = $(this).parent(); var postData = thisForm.serialize() + "&targetPage=" + targetPage; $.post(document.location, postData, function(data) { $('#mainDiv').html(data); }); }); 

PHP

 if( isset($_POST["SubmitArticle"]) ) { $pageID = $_POST["targetPage"]; $text = $_POST["articleText"]; PublishArticle( $pageID , $text ); } 

Código malicioso:

Código insertado en el file JS para escribir el artículo en otras páginas de los usuarios (lo cual no está permitido), el atacante lee la identificación de la página del elemento html utilizando la fuente de la página de visualización (digamos page_id = 12):

 postData = "SubmitArticle=1&targetPage=12&articleText='Muwhahahah'"; $.post(document.location, postData, function(data) { }); 

¿Cuál es la solución si esto es posible?

Tiene razón en estar preocupado, no confíe en el cliente. Nunca.

En su ejemplo, debe validar al usuario antes de publicar el artículo, algo así como:

 if( isset($_POST["SubmitArticle"]) ){ $pageID = $_POST["targetPage"]; $text = $_POST["articleText"]; if( $user->id == $page->userID ){ PublishArticle( $pageID , $text ); } } 

No te detengas allí

Además, no debe confiar en que el cliente le envíe un text de artículo y una identificación de página válidos. Podría ser una inyección de SQL, javascript malicioso, html de salto de página, etc. También debe desinfectar sus inputs.

Creo que tienes un malentendido sobre cómo funciona un server web.

Desde el punto de vista del cliente, todo lo que el server envía al cliente es de solo lectura.

Imagine que ha descargado un file zip de Internet. Luego lo modifica y lo guarda. El process de guardado ocurrirá en su disco duro y no en el server. Cuando edite su file local (en su ejemplo, el file javascript) no se editará en el server, solo en su PC local.

Por lo tanto, usted es libre de hacer / editar sus files locales como lo desee. A less que de alguna manera lo cargue en el server (FTP, por ejemplo), solo estará en su PC local.

Con esto en mente, siempre debe validar los datos también en su server, ya que un usuario experto podría editar su javascript para eliminar la validation de datos y enviarla al server.

Un usuario inteligente puede romper fácilmente la validation del lado del cliente.
el cliente está haciendo esto al final, así que no debemos preocuparnos, hasta que envíe datos incorrectos al server.
así que aplique la validation del lado del server.

 ->like the length of data comming from user ->he is a geniune person to send data or not etc. ->he is on session or not ->check the data type, as expecting(type castings) ->check userId equals to sessionId in server side also not only in client side 

también se lo conoce como Cross-Site Scripting

La creación de scripts entre sitios es una de las vulnerabilidades más comunes en las aplicaciones web. Consiste en inyectar JavaScript malicioso en páginas web utilizando formularios que proporciona su aplicación.

Digamos que estás escribiendo un blog y cualquiera puede agregar un comentario. Si incluye ciegamente lo que los comentaristas han escrito en su página HTML, está abriendo su sitio a los ataques. Puede ser:

 Show a popup to your visitors Redirect your visitors to a site controlled by the attacker Steal information supposed to be visible only to the current user, and send it back to the attacker's site 

En consecuencia, es muy importante estar protegido de esos ataques.

compruebe esto, por ejemplo, para el ejemplo de validation del lado del server

Siempre necesita alguna validation del server en su forma de procesamiento de código php, como:

 if( isset($_POST["SubmitArticle"]) ) { $pageID = $_POST["targetPage"]; $text = $_POST["articleText"]; // here write some code to create a page from pageID if ($user->id == $page->userID) { PublishArticle( $pageID , $text ); } } 

Cuando trate con la input del usuario, asegúrese de que la input nunca se ejecute como código durante toda la cadena de procesamiento (recepción, almacenamiento, lectura, envío, salida). Por lo tanto, nunca proporcione la input del usuario como HTML como .innerHTML en Javascript o .html () como lo hace en jQuery

 //jQuery $('#mainDiv').html(data); //JavaScript mainDiv.innerHTML = data; 

siempre use text en su lugar:

 //jQuery $('#mainDiv').text(data); //JavaScript mainDiv.appendChild(document.createTextNode(data)); 

Si necesita un marcado en sus datos, las cosas se complican mucho y debe proporcionar su propio lenguaje de marcado (networkingucido) como SO o Wikipedia.

Cada vez que un usuario sube algo (que se supone que es visible para otros usuarios) al lado del server, debe asegurarlo. Una forma sería escaping de todos los caracteres especiales (que pueden interpretarse como JavaScript), por ejemplo, convertir todo . a su equivalente en HTML &#46; . También es posible que desee escaping del HTML simplemente convirtiendo todo < to &#60; . Los caracteres que iría son al less estos: <>.=()[] .

Puede verificar códigos especiales aquí . Sin embargo, debería haber alguna biblioteca PHP para eso. No estoy seguro, no soy desarrollador PHP.

En realidad, hay forms mucho más sencillas de ejecutar código en el browser que editar los files js descargados. El usuario puede ejecutar el código js en la console del browser o escribir una extensión del browser que ejecutará el usuario javascript. Y creo que esta es una característica, no un error.

Lo que debe hacer es asegurarse, por parte del server, de que el usuario no hace nada que no tiene derecho a hacer, no puede confiar en nada que provenga del cliente.

Además, si sigues esta regla, el código de usuario que se ejecuta en el browser generalmente solo es un problema cuando puede hacer que ese código se ejecute en el browser de otro usuario (no tienes forma de limitar al usuario a ejecutar cualquier código js en su browser él / ella quiere).

Bueno, no se trata tanto de "cambiar el contenido de un file JS almacenado en caching", sino de modificar cualquier código que se ejecute en un equipo cliente para utilizarlo maliciosamente. Eso, y la mayoría de los browseres hoy en día tienen una console conveniente que le permite crear y ejecutar funciones de JavaScript sobre la marcha, ¡haciendo esto muy fácil!

La solución está en asegurar su código en el server, es decir, en el ejemplo que menciona en el método que toma los datos POST y los publica como un nuevo artículo.

Puede superar esto de muchas maneras, una sería validar la session de los usuarios pasando un token junto con los datos del artículo. Del lado del server, puede crear y vincular un token único para una session de usuario única y almacenarlo allí. Por lo tanto, el token no es el identificador de session, sino un identificador que debe interpretarse como "el pase que permite al usuario x presentar un artículo en condiciones y". Por ejemplo, la página HTML podría estar creando un campo de formulario oculto que contenga esta cadena única que solo es válida para una única request y para una session de usuario específica. Entonces, cuando el usuario envía el formulario, el server no solo valida el contenido del formulario (ya que esto también podría ser alterado por el lado del cliente), sino que también lee el valor del token e intenta encontrar una coincidencia almacenada para los usuarios. la session Y valida si es válida para la acción que el usuario intenta ejecutar. Después de pasar estas validaciones, el token almacenado se puede eliminar ya que ahora no es válido. Puede agregar comprobaciones adicionales para ver si Token se usó en un intervalo de time dado, si la IP todavía coincide, o preferiblemente si el usuario no ha cerrado la session mientras tanto, etc. (SI usa usuarios registrados en su aplicación, esto tiene el beneficio de que solo puede permitir que los usuarios registrados envíen datos, pero esto tiene el inconveniente de que requiere que todos los visitantes se registren antes de que puedan interactuar con el sitio).

Entonces, si un tipo divertido intenta volver a enviar la misma forma pero con datos absurdos (¡o maliciosos!), El código del lado del server negaría la request cuando se usara el token / o la session de los usuarios no coincida con el token almacenado y así es inválido (adicionalmente, también puede usar la validation del lado del server para search palabras traviesas en el text del cuerpo, direcciones de correo electrónico no válidas, etc., pero eso tiene más que ver con desinfectar el contenido de su website, en lugar de security estricta )