First of all, all of this might be a newbie stupid question.
I am developing a web application with Laravel but ended up using tons and tons of Jquery/javascript. I tried to think of all the possible security risks as I was developing but the more I research this topic, the more I am concerned about usage of Jquery/javascript. It seems that dynamic content loading using Jquery/javascript is overall a very bad idea...But I don't want to rework everything since that would take weeks of extra developing of what is already developed. A quick example
Let's say I have a method attached to my div like so
<div class="img-container" id="{{$file->id}}" onmouseover="showImageButtons({{$file->id}})"></div>
And then a part of Javascript
function showImageButtons(id)
{
console.log(id);
}
When I open this in browser, I am able to alter the value of parameter sent to javascript through the chrome inspector.
from this
to this
And it actually gets executed, I can see "some malicious code" being printed to console.
What if I had an ajax call to server with that parameter? Would it pass?
Is there something I don't understand or is this seriously so easy to manipulate?
There are two basic aspects you need to consider regarding web security -
The connection between the browser and your server should be secure (i.e. https), that way, assuming you configured your server correctly, no one can intercept the client-server communication and you can share data through AJAX.
On the server side, you should treat information coming from the client as hostile and sanitize it; That is since anyone can send you anything through your webpage, even if you do input validation on the client side since the your javascript code is executed by the client and therefore in complete control of the attacker. While implanting "malicious code" in the webpage alone is not an actual attack, if an attacker gets you to store that malicious code in the server and send it to other clients she can run her javascript on your other clients browsers and that is bad (lookup "cross site scripting / XSS").
Related
There is some website that publishes some everchanging data. There is no api but I need to access that value programmatically in js. This is a common problem for me.
I am writing a simple js script(HTML/js) hackyAPI, HTML/js or client side is enough for any manipulations I want to do on the data.
But the problem is XMLHttpRequest and cross server permissions. I do not want to introduce server elements just for this. Is there is a workaround considering I just want a typical html respone ?
CORS restrictions are enforced by browsers explicitly to prevent this kind of script (as well as more malicious XSS scripts); whoever is running that site is providing those resources (and paying to serve them up), so unless they're offering a public API it's not really fair to use that data in the way you seem to be trying to do. In this particular case it seems to be directly in conflict with the site's terms of service.
As part of a thought experiment, I am attempting to ascertain whether there is any hope in a server providing a piece of data only for receipt and use by a browser environment, i.e. which could not be read by a bot crawling my site.
Clearly, if that information is sent in the source code, or indeed via any usual HTTP means, this can be picked up by a bot - so far, so simple.
But what about if the information was transmitted by the server instead as a websocket message: Wouldn't this be receivable only by some corresponding (and possibly authenticated) JavaScript in the browser environment, thus precluding its interception by a bot?
(This is based on my assumption that a bot has no client environment and is essentially a malicious server-side script calling a site over something like cURL, pretending to be a user).
Another way of phrasing this question might be: with the web implementation of websockets, is the receipt of messages always done by a client environment (i.e. JS)?
I can't answer about websockets, but a sufficiently motivated attacker will find a way to emulate whatever environment you require. By loading this content through ajax, you can eliminate the casual bots. You can eliminate well behaved bots with robots.txt.
Using WebSocket makes no difference. You cannot escape the following fact: you can always write a non-browser client that looks and behaves to the server exactly as any standard browser.
I can fake: any HTTP headers (like browser vendor etc) you might read. The origin header doesn't help either (I can fake it). Neither does cookies. I'll read them and give it back.
You might get away by protecting your site with strong captchas, and set cookies only after the captcha was solved. That depends on the captcha being unsolvable by bots ..
I have recently taken a position at a large corporation as a Web Developer for one of the company's divisions. For my first task I have been asked to create a web form that submits data to a database and then outputs the id# of that data to the user for reference later. Easy, right? Unfortunately not. Because this is a large company that has been around for a long time their systems are relatively antiquated and none of their servers support server-side technologies (PHP, ASP etc...) and since they are such a large company Corporate IT is pretty much a black hole and there is not any hope of actually getting such tech implemented.
SO! To my question... is there ANY way to do this without server-side? To me the answer is 'no' and I have spent the last week researching on sites like this and others without finding any miraculous work arounds. Really all I have at my disposal are things I can implement without involving IT, so things I can just upload to a web-server.
Also as a note: The web server it is on is supposedly an IBM Web Server (IHS) and the database I am supposed to be connecting to is a MS Access database and the company restricts us to using IE for any web access. As this form is on an internal company INTRAnet site IE is the only browser it will be accessed from.
I know this is a ridiculous situation but unfortunately that is what I am stuck with. Any ideas???
You must have something that takes form data and transforms it for insertion to the database.
There are no javascript libraries that will do this from the browser directly to database (security issues in traversing the network, cross domain issues etc...).
Something will be serving up the web pages - surely this can be the basis of the server side coding you need.
Seeing as you are using IBM HTTP Server (gleaned from comments on your question), there are server side scripting technologies available to you.
Maybe you could create a Web Database with Access Services?
Also as a note: The database I am supposed to be connecting to is a MS Access database and the company restricts us to using IE for any web access. As this form is on an internal company INTRAnet site IE is the only browser it will be accessed from.
That's easy. Use a dirty ActiveX hack to talk toe MS Access directly from the browser.
That's going to be a nightmare to code, but it'll work.
You didn't say which version of Access you're using; this page has information on how to set this up for Access 2003, click on "data access pages".
It's probably better in the long run if you don't solve this problem. Management frustration with IT may help you effect change, or at least get you permission to set up a local web server so you can demonstrate what's possible with the right support.
I would like to test out some interviewees by having them write some javascript that will make requests against my server. I don't want to give them write access to my code base. Javascript runs on the client side, so this should technically be possible. However I know there are browser restrictions that say that the javascript has to come from the server?
I apologize that this is a really dumb question, but how should I proceed?
Edit:::
Ok, so I failed to mention that the entire application is based off sending JSON objects to and from the server.
I think you're thinking of the javascript XMLHttpRequest object itself, in which case, yes the current standard is for browsers to block cross-domain calls. So, you can tell them to pretend they either have a separate proxy script on their own personal domain which will allow them to leap to yours, or to pretend they're building a page directly served from your domain. There's talk of browsers supporting trust certificates or honoring special setups between source and target servers, but nothing universally accepted AFAIK.
Javascript source itself does not need to come from the server, and in fact this is how you can get around this little XMLHttpRequest block by using json. Here's a simple json tutorial I just dug up from Yahoo. But, this calls for your server to provide a json format feed if your server is the intended target.
"there are browser restrictions that say that the javascript has to come from the server"
I'm not aware of any situation where that's the case, only a lack of a console. But...even in those cases there's the address bar and javascript:.
If I misunderstood and you're talking about cross-domain restrictions, then your server needs to support JSONP for the requests so they can make cross-domain calls for data.
You could POST the javascript to your server and then your server can send back some HTML that has the javascript inlined. Sounds like you're trying to set up something is, more or less, a homebrew version of http://jsfiddle.net/; AFAIK, jsfiddle just does a "POST javascript/CSS/HTML and return HTML".
Currently I have developed a site which is used for handle financial transactions. I have seen that some of my customers have done JavaScript injection attacks and have done some transactions which are not possible. As a example I have checked his cash balance before he place the order. But some of them did change that by running the following javascript in the address bar. They have taken the varible name by looking in to page source.
javascript:void(document.accounts.cashBalence.value="10000000")
Since this is critical I want to fixed it quickly. So is there a way to prevent JavaScript injection attacks?
You can obfuscate or hash variable names and/or values. However,
Don't use JavaScript, do every logic in the server-side instead.
In the end it's not even a problem of Javascript. Your server talks to the outside world using HTTP. It sends data using HTTP and receives data using HTTP. Anybody can request data from it using HTTP and anybody can send data to it using HTTP.
Think about this again:
Anybody can send data to your server through the very simple protocol that is HTTP.
The HTML and Javascript you're sending to people's browsers is just a nice help, an interface, to allow them to easily send data to your server. They could do the same using the curl command on their command line or by telnet'ing into port 80 and talk really low-level to it.
If your server blindly obeys any and all commands sent to it without checking their validity, you have no security whatsoever. Security and validity checks belong on the server, not on the client side interface. Because HTML and Javascript aren't the only interface to your server, nor are they in any way protectable and hence trustworthy.
Javascript runs in the user's browser. You ultimately have no control over it and should not trust it. Any verification you do in the browser is merely for the user's convenience so they can be alerted of problems as early as possible.
The backend code that accepts the order should do the authoritative check of the user's balance.
No client-side scripting (including Javascript) is good for verification, It should all be done on the server-side.
It is too unreliable to trust it specially if it is for financial records!!
It should be used for a better "user experience". Form validation while typing or whatever but not this!
Have found that if you make it to where server only excepts out going data not incoming data it works best but that poses a problem, if you are using a website that takes user input on the connected client then your preaty much screwed I sugset a simple java script line that in a sence makes it to where before you can send any java script you have to enter a basic set of variables so in a sence just have a login page start with somthing like this
System.out.printin ("Welcome, Would you like to login to edit?")
Then { System.in = "Yes"}
To prevent Javascript injection, you should have a Validation Feature whenever you allow your user to enter something. Try to use libraries that determine Javascript scripts that are entered to the form.
Also when displaying user inputs, you should Escape Texts to display it as is and will not be evaluated by the browser.
Utilize your server, your should place your business logic to the server and not to the client whether using Javascript or not. All data sent to the client are just view and should not process any business logic.