For SSL Injection:The old "' or 1=1 -- " is a classic, but there are others. Check out who you are logged in as after you do the injection.

For Session and Authentication:As for playing with sessions, try a cookie editor to change your UID.

For Insecure Authentication:Try sniffing the traffic with Wireshark, Cain, Dsniff or Ettercap.

Some code contains naive protections such as limiting the width of HTML fields. If your If you find that you need more room, try using a tool like Firebug to change the size of the field to be as long as you like. As you advance, try using tools like netcat to make your own POST requests without having to use the login web page at all.

You can use the login page normally but then simply change the parameters with Tamper Data. Because Tamper Data is allowing the user to manipulate the request after the request has left the browser, any HTML or JavaScript has already run and is completely useless as a security measure. Any use of HTML or JavaScript for security purposes is useless anyway. Some developers still fail to recognize this fact to this day.

Try SQL injection probing by entering single-quotes, double-quotes, paranthesis, double-dash (--), hyphen-asterik (/*), and closing-parenthesis-hyphen-hyphen ()--)

The first step is not gaining access but recon. Gaining access is actually fairly late in the process. To do recon with respect to SQL injection, try to cause errors to see how the application reacts. Some applications (many actually) fail to install custom error pages as required. Try to find out what database is running then inject special characters for that database. After special characters, try fuzzing major characters sets. Finally, if the application still has not produced useful error messages, then try timing attacks. Your goal is to get a reaction. Well built sites wont act differently even when a database error occurs.

After performing error recon and blind timing attacks, an entry point may be found to begin data extraction. Initially the best data to extract is data about the database itself. Try to answer the questions of what tables, views, columns, functions, procedures, system procedures, and other objects exist. From the MySQL reference documentation: Metadata is data about the data, such as the name of a database or table, the data type of a column, or access privileges. Other terms that sometimes are used for this information are data dictionary and system catalog. INFORMATION_SCHEMA is the information database, the place that stores information about all the other databases that the MySQL server maintains. Inside INFORMATION_SCHEMA there are several read-only tables. They are actually views, not base tables, so there are no files associated with them. In effect, we have a database named INFORMATION_SCHEMA, although the server does not create a database directory with that name. It is possible to select INFORMATION_SCHEMA as the default database with a USE statement, but it is possible only to read the contents of tables. You cannot insert into them, update them, or delete from them. Defense: Web apps should not actual have access to any tables or other objects. Web apps should only have one privilege; EXECUTE. Even then, the web app should only be able to execute on one schema and that schema should only contain the procedures needed explicitly by the application. The procs will still have access to the tables in the table schema because databases run procs with the authroity of the owner; not the caller. It works as if the database sets the "suid" bit on procs. Oracle and SQL Server do allow settings which alter this default behavior; for example causing the procs to run as the caller.

MySQL information schema tables that would likely be useful to recon:

TABLES Table
COLUMNS Table
USER_PRIVILEGES Table
ROUTINES Table
VIEWS Table
TRIGGERS Table

Attempt to recon what type of database is running then study the system functions, tables, and procedures that come with that platform. The built-in functions can come in handy.

SQL Servers accept batch queries but MySQL and Oracle do not. However, Oracle is susceptable to all forms of SQL Injection all the same and provides the greatest number of system functions to exploit. MySQL has fewer functions but the ones provided are very useful.