Basic security measures and Apache logs

.htaccess

I checked and I could access the .php files found in base directory or in order sub folders. I added to the .htaccess the following lines:
   
    #redirect all .php files request to index.php
    RewriteRule ^(.*)\.php index.php [NC]

Later edit:  I tried to access http://myFrontController/config/route.xml  and surprise, it was displayed on screen. So now I decided to  redirect to index.php all file request, whatever extension they have

        RewriteRule ^(.*)\.* index.php [NC]

Unique point to check authorization

@todo

Validating and escaping  input data

I 've read some articles on this topic, there different approaches, the one that I liked most was :  Filter Input, Escape Output. From this discussion on stackoverflow:

"Here are the coding conventions I use:

• values in $_POST, $_GET, $_REQUEST, etc. should not be escaped and should always be considered unsafe
• values should be validated¹ before being written to database or stored in $_SESSION
• values expected to be numeric or boolean should be sanitized² before being written to database or stored in $_SESSION
• trust that numeric and boolean values from database and $_SESSION are indeed numeric or boolean
• string values should be SQL-escaped before being used directly in any SQL query (non-string values should be sanitized²) or use prepared statements
• string values should be HTML-escaped before being used in HTML output (non-string values should be sanitized²)
• string values should be percent-encoded before being used in query strings (non-string values should be sanitized²)
• use a variable naming convention (such as *_url, *_html, *_sql) to store transformed data

Terminology

For my purposes here, this is how I define the terms used above.

1. to validate means to confirm any assumptions being made about the data such as having a specific format or required fields having a value
2. to sanitize means to confirm values are exactly as expected (i.e. $id_num should contain nothing but digits)

Summary

In general (there may be some exceptions), I'd recommend the following:

• use validate filters on input
• use sanitize filters on output
• remember TIMTOWDI - For example, I prefer htmlspecialchars() (which has more options) over FILTER_SANITIZE_FULL_SPECIAL_CHARS or FILTER_SANITIZE_SPECIAL_CHARS (which escapes line breaks)"

What I did

1. Validating data entered in the login form

- new class to store validation methods \validation\Valid.class.php
- use a regex to validate user and password:  '/^[a-zA-Z0-9_-]{3,16}$/i' (white list validation). A resource for validation regex: https://www.owasp.org/index.php/OWASP_Validation_Regex_Repository
- use the validation method in Admin.class.php :

    if (Validation::userAndPass($_POST['username'],$_POST['password']))

If the input is not valid show Javascript pop up message and redirect to login page (I know, I am not checking to see if Javascript is enabled)

    $message = "The entered value is not valid.";
    echo "<script type='text/javascript'>alert('$message');window.location = '/admin';</script>";


I've read about the filter_var() function from PHP and the types of filters available and I feel this regex is doing just fine for the job.
More on this :  http://code.tutsplus.com/tutorials/getting-clean-with-php--net-6732

The other places where data enters in the application are the new entry post/edit post form. I will apply "htmlentities()" function
before saving them on the Database.
-in BlogModel::newPost and BlogModel::updatePost I apply htmlentities()

  $result=$db->newPost(htmlentities($Author), htmlentities($Category), htmlentities($Text), htmlentities($Title), $Slug)

- in Blog::renderPost I decode the content of the post:

$new_content.= "<tr>".html_entity_decode($row['ActualPost'])."</tr></br>";

2. Use prepared statements and parameterized queries. - I am already doing that, I should just set connection attributes as mentioned here: http://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php

"What is mandatory however is the first setAttribute() line, which tells PDO to disable emulated prepared statements and use real prepared statements. This makes sure the statement and the values aren't parsed by PHP before sending it to the MySQL server (giving a possible attacker no chance to inject malicious SQL)."

            $db_conn = new PDO('mysql:host=localhost;dbname=myblog', $user, $pass);
            $db_conn->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
            $db_conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

Saving Database user and password somewhere safe

As usually StackOverflow offers the answers: http://stackoverflow.com/questions/97984/how-to-secure-database-passwords-in-php
From the list of answers I picked on the below option:

If you're hosting on someone else's server and don't have access outside your webroot, you can always put your password and/or database connection in a file and then lock the file using a .htaccess:

<files mypasswdfile>
order allow,deny
deny from all
</files>

As I am already denying access to any .php file I didn't added anything else to the .htaccess

Also for the future:  "The usual solution is to move the password out of source-code into a configuration file. Then leave administration and securing that configuration file up to your system administrators. That way developers do not need to know anything about the production passwords, and there is no record of the password in your source-control."

 Apache logs

You can find those in the apache \logs on Windows machines.

1. access.log gives you information about whar  URIs were requested, by whom, and the answer from server, so you can see the URLs attacks:

The log file entries produced in CLF will look something like this:

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 

Each part of this log entry is described below(source http://httpd.apache.org/docs/2.2/logs.html ):

127.0.0.1 (%h)

This is the IP address of the client (remote host) which made the request to the server. 

- (%l)

The "hyphen" in the output indicates that the requested piece of information is not available. In this case, the information that is not available is the RFC 1413 identity of the client determined by identd on the clients machine. This information is highly unreliable and should almost never be used except on tightly controlled internal networks. 

frank (%u)

This is the userid of the person requesting the document as determined by HTTP authentication. This value should not be trusted because the user is not yet authenticated. If the document is not password protected, this part will be "-" just like the previous one.

[10/Oct/2000:13:55:36 -0700] (%t)

The time that the request was received. The format is:

[day/month/year:hour:minute:second zone]

"GET /apache_pb.gif HTTP/1.0" (\"%r\")

The request line from the client is given in double quotes. The request line contains a great deal of useful information. First, the method used by the client is GET. Second, the client requested the resource /apache_pb.gif, and third, the client used the protocol HTTP/1.0. It is also possible to log one or more parts of the request line independently. For example, the format string "%m %U%q %H" will log the method, path, query-string, and protocol, resulting in exactly the same output as "%r".

200 (%>s)

This is the status code that the server sends back to the client. This information is very valuable, because it reveals whether the request resulted in a successful response (codes beginning in 2), a redirection (codes beginning in 3), an error caused by the client (codes beginning in 4), or an error in the server (codes beginning in 5). The full list of possible status codes can be found in the HTTP specification (RFC2616 section 10).

2326 (%b)

The last part indicates the size of the object returned to the client, not including the response headers. If no content was returned to the client, this value will be "-". To log "0" for no content, use %B instead.

2. error.log - in my case was a large file which NotePad++ couldn't open. I used VIM(http://www.vim.org/download.php#pc) and it worked like a charm.

The format of the error log is relatively free-form and descriptive. But there is certain information that is contained in most error log entries. For example, here is a typical message.

[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] client denied by server configuration: /export/home/live/ap/htdocs/test

The first item in the log entry is the date and time of the message. The second item lists the severity of the error being reported.