Can someone edit javascript file offline to run malicious code?

Question

I am worried about something related to javascript files of my website, I am not sure if this is doable.

Js files will be downloaded when someone visits a website, what if someone edited the downloaded js script and inserted his own code, then refreshed the website. In the new refresh the website will read the edited Js file and will run the malicious code. The malicious code might be used to run some code at the server in normal ways.

Example:

A user is only allowed to post an article in his page:

HTML

Article form will only show for the user in his page.

<?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 );
}

Malicious Code:

Code inserted in JS file to write article on other users pages (which is not allowed), the attacker reads page id from html element using view page source (lets say page_id=12):

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

What is the solution if this is possible?

Answer 1

You are right to be worried, don't trust the client. Ever.

In your example you should validate the user prior to publishing the article, something like:

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

    if( $user->id == $page->userID ){
      PublishArticle( $pageID , $text );
    }
}

Don't stop there

In addition, you should not trust that the client will send you valid article text and page id. It could be a SQL Injection, malicious javascript, page breaking html, etc. You need to sanitize your inputs as well.

Answer 2

I think you have some misunderstanding on how a web-server works.

From the client point of view everything the server sends to the client is readonly.

Imagine you have downloaded a zip file from the internet. You then modify it and save it. The save process will happen on your hard-drive and not on the server. When you edit your local file (in your example the javascript file) it won't be edited on the server, just on your local PC.

Therefor you are free to do / edit your local files like you want. Unless you somehow upload it to the server (FTP for example) it will only be on your local PC.

With this in mind you should always validate the data also on your serverside as a skilled user could edit your javascript to remove data validation and send it to the server.

Answer 3

A smart user can easily break client side validation.
client is doing this in its end so we need not to worry, un till he is sending a wrong data to server.
so apply the server side validation.

->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  

it is also known as Cross-Site Scripting

Cross-site scripting is one of the most common vulnerabilities in web applications. It consists of injecting malicious JavaScript into web pages using forms that your application provides.

Let’s say you’re writing a blog, and anyone can add a comment. If you blindly include what commenters have written into your HTML page, you’re opening your site to attacks. It can be:

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

Consequently it is very important to be protected from those attacks.

check this for example for server side validation example

Answer 4

You always need some server validation in your form processing php code, like:

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 );
  }
}

Answer 5

Whenever dealing with user input make sure the input is never executed as code during the whole chain of processing (receive, store, read, send, output). Therefore never render user input as HTML like .innerHTML in Javascript or .html() like you do in jQuery

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

//JavaScript
mainDiv.innerHTML = data;

always use text instead:

//jQuery
$('#mainDiv').text(data);

//JavaScript
mainDiv.appendChild(document.createTextNode(data));

If you need markup in your data then things get much more complicated and you should provide your own (reduced) markup language like SO or Wikipedia are doing it.

Answer 6

Whenever a user uploads anything (which is supposed to be visible by other users) to the server side you have to secure it. One way would be to escape all special characters (which may be interpretted as JavaScript), for example convert all . to its HTML equivalent .. You may want to escape HTML as well simply by converting all < to <. The characters I would go for are at least these: <>.=()[].

You can check special codes here. There should be some PHP library for that though. I'm not sure, I'm not PHP developer.

Answer 7

Actually there are much easier ways to run code in the browser than editing the downloaded js files. The user can run js code in the console of the browser or write an browser extension that will run user javascript. And I believe this is a feature, not a bug.

What you need to do is to make sure on the server side that the user does not do anything that he/she has no right to do, you can not trust in anything coming from the client.

Also, if you follow this rule user code running in the browser is usually only a problem when he/she can make that code run on other user's browser (you have no way to limit the user from running any js code in his/her browser he/she wants).

Answer 8

Well, it is not so much a "changing the contents of a cached JS file"-issue, as any code that runs on a client machine can be altered for malicious use. That, and most browsers nowadays have a convenient console allowing you to create and run JavaScript functions on the fly making this nicely easy!

The solution is in securing your code on the servier-side, i.e. in the example you mention in the method that takes the POST data and publishes it as a new article.

You can overcome this in numerous manners, one would be validating the users session by passing a token along with the article data. Server side, you create and pair a unique token for a unique user session and store it there. The token thus isn't the session identifier, but an identifier that should be interpreted as "the pass allowing user x to submit an article under conditions y". So for instance the HTML page could be creating a hidden form field containing this unique string which is only valid for a single request, and for a specific user session. So when the user submits the form, the server not only validates the contents of the form (as this too could be tampered with on the client side), but also reads the token value and tries to find a stored match for it for the users session AND validates whether it is valid for the action the user is trying to execute. After passing these validations, the stored token can be removed as it is now invalid. You could add additional checks to see whether to token was used in a given time slot should you want to, whether the IP still matches, or preferably whether the user hasn't logged out of that session in the meantime, etc (IF you use registered users in your application, this has the benefit that you can only allow registered users to submit data, but this has the down side that it requires all visitors to register before they can interact with the site.).

So if a funny guy tries to re-submit the same form but with nonsensical (or malicious!) data, the server side code would deny the request as the token was used / or the users session doesn't match the stored token and thus is invalid (additionally, you could also use server side validation to look for naughty words in the body text, non-valid e-mail addresses, etc, but that has more to do with sanitizing the content of your website, rather than strict security).