Wednesday, December 31, 2014

Opencart security, a must-have checklist for webmasters

Just played with the opencart, which is a very popular e-commerce solution for SMBs . and If you are tech-savy webmaster, you may know that is pretty safe in terms of code security. before this version, you may have all kinds of issues like XSS, SQL Injection. but is pretty safe though. 

However, code safety doesn’t means operation safety. I will show you what does this mean in 4 examples, you may have those issues already which means your customer’s credit card or sensitive information is leaking now.

Turn off Debugging for both usps and USA epay from the admin console. this is very important. (this is rule number 1)

if you turn on the debugging for usa epay in the following screen, gosh, you need pay attention .


if you turn on debug logging, check the system/logs folder, a file called usaepay_server_debug.txt will have all the Live credit card information and customer information.

to be worst, the hacker might just access to see all your raw credit card information.

usaepay_server_debug.txt to see all debug information.

Here is one real example that one hacker is pulling this file


risky? though I put a fake information there. if you are not lucky, your customers’s credit card is gone, cross fingers.


Rule number 2, put a .htaccess file to block /system/logs access.

this is very obvious, what every issue you have , you may put sensitive information into the logs folder, like stack trace? customer information, error to running a sql statement?

put a .htaccess under system/logs with content “Deny from all”, locked down the access from public access.

this is a easy fix, definitly you should do it.

Rule number 3, check your access logs for POST requests. since most user should be get Only, some hacker might found site voluability and inject some evile scripts like webadmin.php, get is limited by the url length, definitly the hacker will send a post request to inject the blackdoor.

you can write a cron job with python script to do a daily access, and email you daily to double check those special posts, if you see special urls with POST, pay attention.

Rule Number 4, suPHP, if you run suphp as the PHP handler. double check the execution logs

suphp is fast, but it runs with a high privileged user might shoot the gun to yourself. so check the suphp logs to see which php file get executed daily.

here is one pythong script to dump out the files list daily. typicall you should only see index.php and admin/index.php, no other evil php like webadmin.php? images/index.php


once you have those 4 rules ready, you should be feel much safer about your website operation security. any more questions, email me and I will get back to your for more details or even do a consultation for you .


Thursday, December 25, 2014

Iptables rules , Drop or Reject?

By Default, Pinging is fine to both and


If we turn on the firewall, to Drop icmp to google, and Reject UDP to


then ping google by ip which is rejected by firewall policy


What about TCP


SO, Drop means pretend the port is not open, which is like a implicit denial .

Reject means explicit denial.

Friday, December 19, 2014

log4net legacy configuration

just got one legacy app with log4net early version bundled, something wrong and there is no way to see the log . here is the trick

if you use refelctor, you can see the assermbly attribute. [assembly: DOMConfigurator(ConfigFileExtension="log4net", Watch=true)]


then for the config file, should you yourexe.exe.log4net, you can tell from the logic


one sample config

<?xml version="1.0" encoding="utf-8"?>
    <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
    <appender name="FileAppender" type="log4net.Appender.FileAppender">
      <file value="logfile.txt" />
      <appendToFile value="true" />
      <layout type="log4net.Layout.PatternLayout">
        <conversionPattern value="%date: %-5level – %message%newline" />
      <level value="INFO" />
      <appender-ref ref="FileAppender" />


Tuesday, December 16, 2014

Windows azure Mobile service, delete expired data automatically.

It turns out Azure mobile service is way more powerful than you think. I setup a simple mobile service table to hold some incoming logs.

on the table itself, I created one node.js API for insert, basically insert a timestamp in long named dt. (I found this very useful for you to delete the old data , like logs week ago)


then every incoming logs will be applied with the timestamp. now create another scheduler to run  daily and check to delete old logs


and config it to run daily


then in the log you will see the daily run


Locations of visitors to this page