Home
Log4js is a logging API for JavaScript.
- Prevent double carriage return with FileLogger
var oLogger = new Log4js.getLogger('myDomain');
oLogger.setLevel(Log4js.Level.ALL);
var oLayout = new SimpleLayout();
oLayout.LINE_SEP = '';
var oAppender = new FileAppender(oLogger, 'output.txt');
oAppender.setLayout(oLayout);
oLogger.addAppender(oAppender);
Any suggestions on following proposals are welcome.
- Add the feature to configure logging also via property file like log4j.
- How could such property file be found?
- Where should it be located?
- How will it be parsed?
- An XML file can also be used to configure logging, getting it via AJAX and parsing it, like DOMConfigurator in log4j.
If you are using Log4JS you can log the data in some different ways by the loggers provided in the library:
- WindowAppender: Opens a new window in the browser and insert log messages in real time
- WindowsEventAppender: Send log messages in the MS Windows event manager.
- FileAppender: Write log messages in a local file on the client.
- AjaxAppender: Allow to send log messages to the server with asynchronous HTTP request. There you can process the logging events like you want on server side (ASP.NET, Java Servlet, JSP, PHP, Ruby, etc.).
- MetatagAppender: Add log messages as meta data.
There are some security issues you have to attend. Remember allways the old rule „Never trust users data input!“ I will extend this rule to „Never trust clients data input!“
The Log4JS-API is well designed and will hopefully only do what the developer want. But there is one important point of view: Its written in JavaScript and the script is executed on the clientside. Why that could be a problem? Everone can control the JavaScript code execution by some clientside tools (e.g. Venkman JavaScript Debugger). A black hat user can modify the variable content so that data will be sent by the Logger you dont want!
Especially if you are using the AjaxAppender this is an important reason to check the data sent by the Logger before you are using it on the server side. The normal way is that a serverside script (e.g. a PHP-Skript or an JSP-application etc.) receive the logging data and do something with it: Writing to a file, in a database or sending via e-mail or whatever else.
But you have to check the data when it is received before you do something further with it. Because a prospective attacker could injected some malicous data into the post request. Like described above the attacker can manipulates the variable content directly in the JavaScript code in the client application or he can send manipulated XMLHttpReqeuest-objects to your serverside application. Also its possible to penetrade the serverside application directly via manipulated GET- or POST-requests. So it may be possible to do some SQL or remote code injections to your server application.
What can you do to avoid this attack vector?
- Never using in your serverside programming language the GET-variables. In PHP for example you can use a superglobal variable called $_REQUEST. It gives you all variables sent via GET, POST or by cookies. Log4JS only uses the POST-method. If you are checking in which way the data is received and only accepted it send by the POST-method you can avoid simple urlencoded attacks.
- Using whitelists to check the data! You can not knwo what a prospective attacker will send to penetrate your server. But you know, if aour application is well designed, what your application will send, unless its not compromised. So define a handfull messages you need to track the applications behaviour. On your serverside you can check if the log messages contains the data you specified. If not you should discard the data. For example: You defined only some errornumbers like „0“ for everthings allright, „1“ for an error and so on. And you are only sending this numbers to your server. So you can check on the serverside if the data contains something else than your defined errror codes.
- Never try to clean the data. Its allways a weak implementation to clean the data to get rid of the malicous parts becaus their exists much ways to hide malicous code. Its very difficult to write filters an regular expressions to find all of them. And you have to keep your blacklist allways uptodate, if there is a new way to masquerade malicous code. On the other hand a white list you only have to update if you are going to change your defined messages or your are changing some parts of your application.
Serverside vulnerability & CSRF
There is not only the problem that someone send compromised data via the Loogger to your serverside application. The most of the Appenders provided by Log4JS logs the data on the clientside. Now you can ask, wheres the problem? What benefit have a black hat if he hacks the local code to send malicous logging data to himself? I will strike out a little bit more. It's not only possible that your clientside code will be compromised to do some attacks. Its also possible to penetrate your serverside application to modify things. Maybe your serverside code allows some remote code injection or cross site scripting. Then it could be possible to modify the logging code, which will be send to unsuspecting users, that way that the logger will send some malicious code to the local appenders. That is a way of second order attacks which can be use to do cross site request forgery. Let my describe some scenarios:
- If I found a way to hack the serverside application, so that the MetatagAppender would be compromised I can insert malicious data into the metatags in the clientside. If I found a way to insert some own JavaScript by this way I can do via DOM everthing I want to do. So I can do more mal things in the conntext of the user and of yours site!
- An other scenario could be to write some „strange“ things to the WindowsEventAppender. And we all know that in Windows are some nice vulnerabilities. I did not try this appender. But I can imagine that there are some nice second order attacks are possible.
Like described obove it is not realy possible for you to secure the clientside script code. Becaus its running on the client and with the right tools the client user can get full control over it! But to avoid the scenarios above you have to secure your serverside application as much as possible! You have to check everything sent to your server and check if it could be malicious. Never trust data send via HTTP requests, never trust the data send by XMLHttpRequest objects and also never trust the data received by your own cookies!
If you are using Log4js, please feel free to add a link to project, organisation or company: