Marketplace/Reviewers/Apps/Guide/Firefox OS Add-on Security: Difference between revisions

Jump to navigation Jump to search
obfuscation tipps added
(moved)
 
(obfuscation tipps added)
Line 117: Line 117:
|| Look for creation of script elements.
|| Look for creation of script elements.
|}
|}
= Guide =
== Obfuscation ==
If the add-on is completely obfuscated, ask for the cleartext code for review, and affirm that the cleartext you are reviewing is what compiles exactly into the obfuscated add-on in the queue. In doubt, escalate.
There's a sneakier obfuscation technique that tries to hide malicious code in plain sight. Most often you will see a combination of fancy string encoding (e.g. "\x68\x74\x74\x70" instead of "http"), indirect object access (i.e. through a copy in a variable), bracket notation for object access (e.g. using ''xhr["open"]'' instead of ''xhr.open''), and helper variables with inconspicuous or misleading names.
Reviews likely happen under some sort of time pressure. To speed things up, you skim the code for the interesting parts, you grep for a few suspicious keywords, but there's hardly time for understanding every single line. In such a scenario, it is easy to miss that
var trigger = 'EL_max_timer_precision';
var timelogger = this;
var msg = "\x73";
msg += trigger[3];
msg += msg[0];
var mode = "\x61\x64\x64" + trigger[0];
mode += "vent" + trigger[1] + "ist";
mode += trigger[10] + "ne" + trigger[11];
var result = timelogger[mode];
result(msg, this);
isn't actually logging time, but covertly installing a listener for ''sms'' events. While certainly not the most elaborate example, it might still get across the idea of "hiding in plain sight".
=== Take-aways ===
* Searching for well-known keywords is a good start, but not always enough.
* Develop an eye for common obfuscation techniques.
* Any form of partial obfuscation should immediately ring alarm bells.
* Easiest way to see though is by selective execution of code snippets.
Confirmed users
184

edits

Navigation menu