Thursday, August 31, 2017

SQL(and other) Injection testing for beginners

I was testing a piece of our software the other day and came across this. When I first started it took me forever to figure out what was meant by this. Code injection doesn't necessarily have to be SQL that is being executed but can also be javascript or any other type of code that is put into a field in a program that is not supposed to take that kind of information.

What I saw the other day was placing javascript into the place where a name was supposed to be and what would happen is that the javascript would run when loading a page that had that information on the page. That would be a javascript injection attack.

The reason why it is called SQL injection is because at first it was people entering in SQL (the language of databases) in places that shouldn't have it and then they would have access to the database to do what they wanted with it.

"And thatsssss...bad?" (emperor's new groove) yes extremely they now have access to all information that is stored in your database they also have access to manipulate the tables how they want.

When testing for this one thing you want to do is to use different SQL commands in order to test a variety of possible attacks. Here are a few examples of SQL to test input areas of your program

"SELECT * FROM Xtable" Xtable = any table in your database; this tests basic keywords
add "or 1=1" to the previous statement to test against returning all rows in that table
Type text ";Drop Table X;" This will finish the search query and then drop a table in the database

These are just a few and these are only for the SQL based attacks there are other injection attacks like that also has vulnerabilities like this.

The javascript if you type <script> Javascript</script> into your input and it executes the javascript you have a vulnerability.

This is basic (very basic) idea of what javscript injection is and some basic things to how to test for it.

Here are a few pages that explain some more/different ideas on SQL injection.



Friday, August 4, 2017

Clean Code

At work we have been reading and discussing as an engineering department. While I don't agree with everything there are definite aspects of it that I have found extremely helpful when looking at old/legacy code. I would like discuss a few of the points that were most helpful.

1. Naming variables
This is sooo crucial. I have found, no joke, variables called 'a' or 'b' in code. Let me tell you that this is the most annoying thing. Because now I have to spend 30 to 45 minutes (if i'm lucky) trying to find out what the variables are supposed to be. This is especially annoying with parameter variables.
I found it most helpful to pull someone over and ask them if they know what the variables are supposed to represent. That way I get the opinion of someone who has know idea what the code is actually supposed to do. I also found it helpful to refactor after I finish writing the function or segment of code to make sure the variables store what they are supposed to store.

2. Functions doing just one thing and naming functions
You would not believe how helpful this is. I was recently working in a language called cold fusion and I kid you not there was a function not a class that basically was an API. That is hopefully an extreme example but none the less having your function do just one thing is super helpful for testing, refactoring and using the function itself. One of the things this does is keep your parameter list down which makes usage significantly easier to navigate. The naming of functions is also something you should keep in mind when righting clean code. make sure your function is named what it is doing

3. Abstract out all the things
You should put things where they go and avoid clumping.What I mean by that is making sure you have your back end code separate from your front end code and connect them with your API's. If you follow number 2 this should be pretty easy to follow. if you do this your code will be the easiest to maintain and to refactor later on.

4. refactor often and make sure your code is covered with tests (of some sort)
The reason i put these together is if you don't have the tests then you will not be able to refactor with confidence. Refactoring often will help you avoid potential issues. This is how you convert legacy code to clean code. So if you don't have tests already write them, then start the refactor process. I would suggest starting this sooner rather than later because of the potential technical debt that you could be accruing.

So these points and this book more refer to software developers when stating the various points and as it is true that these points do refer mostly to developers I have found some of the dirtiest code written by SQA for automation tests. So I implore ANYONE who writes code to make sure that you write clean code.