Janko in a Jar

At the first post on this topic I wrote a list of known vulnerabilities of a typical LAMP web-app. Plan is to investigate where exactly does each of them apply to the web-app I am making more secure and patch them.

In the process I realized that there is another perspective/question here that is also very important. One is to fix “all” the holes, but you also have to ask yourself.

“What am I really trying to prevent here?”

In our case. We need to prevent anyone getting to (identifying) personal information of the users. That is the most important thing and all others are magnitudes of less important. Every other data we hold, if it gets “stolen”, meh.. if they delete, change it, we have the backups. But the privacy of the users is sacred. Too bad I can’t say what exactly we did now in this regard.

The analogy is this. You have area of people infected with some virus X. You can put roadblocks, test and disinfect all outgoing people, spray their cars, forbid mail communication, put fences to prevent wild animals to spread it but sooner or later something will get through. Or you can focus on a virus and find a way to prevent itself from spreading.

You can try to prevent the problem to get “out” , or you can try to remove the problem in the first place

Well, nothing is as perfect as theory so we do both.

QUBIDRAW (the early release) is online for a while now. I have very little time to push the development forward but nice things happen on it anyway. Here are few of the pictures that kids have drawn:

QUBIDRAW is a online concept of my KUBI game. I plan to make many more activities and polish the thing up few times. Flash part is being made in Haxe, webpart in PHP. They communicate via my tiny RPC spec STRPC - SoTinyRPC.

input data related to DB (SQL injections, wrong unexpected data..)

SQL injections threat is system wide and is best to be solved on a systematic level on all the communication with the database. We use PHP PEAR DB’s quoteSmart on all the queries. In addition all function in our database level have explicit checking for type of input variables and script is stopped if it doesn’t match.

An example of such back-end function is:

function getItemsOfMusic($musicId)
{
	Validator::mustBeInt($musicId);			

	return $this->db->selectRows(array(
		'from' =>'abt_music_items',
		'where'=>"id_musics = $musicId",
		'order'=>'sort, is_set, name'));
}

All this fuss about SQL injections in a little stupid with php+mysql anyway since the core function (mysql_query) doesn’t support multiple queries anyway and you need that I think to do SQL injection.

The time has come that I have to work on security at one bigger project. I know the basics but I digged in that much. I will post my notes here.

Web Application (WA) security is a very wide and also vague term. I need to break it down to concrete things — to the specific security threats for web-apps (WA) and then explore one by one.

1. input data related to DB (SQL injections, wrong unexpected data..)
2. input data when related to HTML, JS, VBs..(script injection and all that it can bring)
3. User authentication (password, login security)
4. sessions and cookies (stolen, replayed, hijacked)
5. directory traversal
6. shell escape (injection)
7. DB password hard-coded in web-reachable file
8. XSS
9. CSRF
10. Canonicalization, Unicode

Some of these threats can be eliminated by just concise coding (and being aware of them), other need some special devotion. I will explore them deeper soon.