Security Flashcards
How is register globals a potential security risk and how can it be avoided? From PHP 4.2.0 - 5.3.0
When on, register_globals will inject your scripts with all sorts of variables, like request variables from HTML forms. This coupled with the fact that PHP doesn’t require variable initialization means writing insecure code is that much easier.
when the default value for the PHP directive register_globals went from ON to OFF in PHP » 4.2.0
From PHP 5.3.0 it was deprecated in version 5.4.0 it was removed.
How might website be compromised through database query?
Through Direct SQL Command Injection , which is a technique where an attacker creates or alters existing SQL commands to expose hidden data, or to override valuable ones, or even to execute dangerous system level commands on the database host.
This is accomplished by the application taking user input and combining it with static parameters to build an SQL query.
How might you prevent SQL injection in website?
1-A hacker may gain access owing to a lack of input validation and connecting to the database on behalf of a superuser or the one who can create users, as a result the attacker may create a superuser in your database.
2-If your database supports the UNION construct, the attacker may try to append an entire query to the original one to list passwords from an arbitrary table. Ensure encryped password fields.
What avoidance techniques can you use to avoid attacks on database ?
SQL injection attacks are mainly based on exploiting the code not being written with security in mind. Never trust any kind of input, especially that which comes from the client side, even though it comes from a select box, a hidden input field or a cookie.
Never connect to the database as a superuser or as the database owner. Use always customized users with very limited privileges.
Use prepared statements with bound variables. They are provided by PDO, by MySQLi and by other libraries.
-Check if the given input has the expected data type. PHP has a wide range of input validating functions, from the simplest ones found in Variable Functions and in Character —-Type Functions (e.g. is_numeric(), ctype_digit() respectively) and onwards to the Perl compatible Regular Expressions support.
- If the database layer doesn’t support binding variables then quote each non numeric user supplied value that is passed to the database with the database-specific string escape function (e.g. mysql_real_escape_string(), sqlite_escape_string(), etc.). Generic functions like addslashes() are useful only in a very specific environment (e.g. MySQL in a single-byte character set with disabled NO_BACKSLASH_ESCAPES) so it is better to avoid them.
- Do not print out any database specific information, especially about the schema, by fair means or foul. See also Error Reporting and Error Handling and Logging Functions.
- You may use stored procedures and previously defined cursors to abstract data access so that users do not directly access tables or views, but this solution has another impacts.
Besides these, you benefit from logging queries either within your script or by the database itself, if it supports logging. Obviously, the logging is unable to prevent any harmful attempt, but it can be helpful to trace back which application has been circumvented. The log is not useful by itself, but through the information it contains. More detail is generally better than less.
Administrator has set up php binary as an independent standalone interpreter , what are the two ways by which it is vulnerable and how does php block it?
2- If the secret file is http://my.host/cgi-bin/php/secret/doc.html The
CERT advisory » CA-96.11 recommends against placing any interpreters into cgi-bin, otherwise..
1- possible security attack:- accessibility through system files - through query string in URL after ? Attacker can insert command to interpreter.
Php stops this by not interpreting any commands from the URL .
2- accessing any web document on server :- using path information part of the URL after the binary name. Usually we server config directory are setup to redirect requests of documents (apache:Action).
PHP checks access permission to the directory “/secret” before creating redirect request, however if information is already given in form , no access checks are made for web server file, “/secret/script.php” but only for the /cgi-bin/php file. This way any user able to access /cgi-bin/php is able to access any protected document on the web server. In PHP, runtime configuration directives cgi.force_redirect, doc_root and user_dir can be used to prevent this attack, if the server document tree has any directories with access restrictions.
