Hi Allex,
Read about this malware here:
http://blogs.technet.com/antimalware/Never trust user input, used in a query, always use add-slashes at variables. In a numeric SQL field do not use slashes in a WHERE statement, else you are vulnerable and your open to SQL injection. Encrypted data from a cookie and from a URL-variable should always be add-slashed.
So the following string 'Mtp0cm91Ynk6M2U5YzliNzcxZGZkY2QyMjlhMTk0MDE1ZmViYTQ1MWM=' had been add-slashed(). The decoded base-64 string was not add-slashed as such within a script, and bingo vulnerable! Always do this for cookie, post, variable,
Was the problem here: hxtp://www.problemefiat.ro/scripts/ac_runactivecontent.js
Websites can detect if you've got Flash installed. How does that work and could it be used for both of my goals? " - it's quite a bit simple, your browser try to render some additional files, with some specific formats such as flash .swf and I the browser doesn't find installation, than will be start downloading, or you will got the option to download that program. Flash also use AC_RunActiveContent.js please take a look at this js, people usually put this on their webpages
if (AC_FL_RunContent == 0) {
alert("This page requires AC_RunActiveContent.js.");^^
} else {
AC_FL_RunContent( 'codebase','xttp://download.macromedia.com/pub/shockwave cabs/flash swflash.cab#version=8,0,0,0','width','981','height','635','id','build5','align','middle','src','build5','quality','high','bgcolor','#ffffff','name','build5','allowscriptaccess^^','sameDomain','allowfullscreen','false','pluginspage','xttp://www.macromedia.com/go/getflashplayer','movie','build5' ); //end AC code
} vulnerable to SQL exploit
Protecting against SQL injection is easy:
*
Filter your data.
This cannot be overstressed. With good data filtering in place, most security concerns are mitigated, and some are practically eliminated.
*
Quote your data.
If your database allows it (MySQL does), put single quotes around all values in your SQL statements, regardless of the data type.
*
Escape your data.
Sometimes valid data can unintentionally interfere with the format of the SQL statement itself. Use mysql_escape_string() or an escaping function native to your particular database. If there isn't a specific one, addslashes() is a good last resort. But Actually the most effective way to defend yourself against SQLI is using prepared statements:
http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.htmlAddslashes() is rather dangerous because it gives a false sense of security. In facts, it can be fooled by exploiting character set mismatches between input and database, and it works (badly) with MySQL only (none of the other SQL-compliant databases use slashes to escape special characters).
If you can't use prepared statements, e.g. because you're stuck with PHP 4 and the its old mysql client API, you must escape all the data you put in your SQL statement with mysql_real_escape(), rather than addslashes()
polonus
