Destiny

In some cases you choose your own destiny and in other cases it’s chosen for you.
My first name is “Or” – an odd name for someone who works in web application security research; actually “Or” is a Hebrew name meaning “light” (most Hebrew names have a meaning) so I guess my destiny could have been to work for the national electrical company or perhaps as a bulb salesman :)
Actually, there’s a well-known joke that I particularly relate to – see below.




In my case you can replace “DROP table students” with “OR 1=1”

I’ve had a few annoying experiences of my own when trying to register to applications that went and rejected me because of my first name, saying it’s not valid :(

This leads me to the issue that I wanted to talk about which is security rules writing.

While offensive security has the charm and the glory, defensive security often takes the blame if either you block the wrong users (searching for SQL logical condition “or” in user input) or you miss attack detection and the application gets exploited. Writing the right security rules is not an easy job; They should be answering the following:
• Full security detection coverage
• No false positives
• No false negatives
• No performance impact to the security device (that can lead to performance impact to the protected application).

Now the real magic is in finding the right way to balance between all these requirements.