How to effectively test and locate application security flaws?

3

I'm facing a serious problem with hackers and / or crackers on the site developed for a city hall. I tested SQL MAP on every page of the site. I tried the ftp lock, looked for files injected into the site, searched for viruses, malwares and backdoors and so far nothing ...

So I came up with this question, how to test the application effectively and find security flaws related exclusively to the application?

I think that in order not to be so broad the question could be focused only on the WEB environment ... if the person who answers the question thinks that it can cover all the content it will be very welcome too: D

I would also like if possible that the answer be quite generic and can be applied to any form of development (within the limitations of languages)

  

Application information:
  Language: PHP
  Database: MySQL
  Connections: mysql_connect ¬¬ (not my fault)   

     

Attack Focus: Database

     

Common Issues
  Script Injection for page redirect
  Injection of images within the news and highlights
  Injection of files to backdoor

     

Items that do not cause problems (hear no attempts)
  DoS Attacks
  Brute-Force Attacks

     

Fixes in the first instance
  Changing database credentials
  Changing the admin password (current hash -> df8bce1285196dddc104c22f15665dac)

I had already asked What the code below (written by a cracker) does? and had posted the code from one of the files that were already injected into the site ...

I did a scan on ftp and made sure there is no malicious file inside it ...

All gets and posts are validated as follows

if(isset($_GET['t'])){
    $ids = (int)mysql_real_escape_string($_GET['t']);
    if(!is_numeric($ids)){
        $ids = '1';
    }   
} else {
    $ids = '1'; 
}
    
asked by anonymous 16.09.2014 / 20:00

2 answers

4

According to his description of the most common problems, I would divide the attention into two fronts:

  

Script Injection for Page Redirection

     

Injection of images within the news and highlights

This is a sign that user inputs are not being sanitized properly. But in this case, I'm not referring to correctly formatting SQL (something that prepared statements would help), but rather to properly escaping HTML

.

In a Web application there are several points where a user-supplied entry is shown back to it as part of a page. Even if this entry is properly "escaped" when inserting in the bank, this does not mean that it is safe to be embedded in a page. For example, there are no invalid SQL characters in the string <script>alert(1);</script> . But if a user entered this in a text field, what should be included in a results page is &lt;script&gt;alert(1);&lt;/script&gt;

(data to be returned with values of a input are not safe either, eg teste"><img src="foo )

Escaping content before sending to the bank prevents SQL Injection . To prevent against JS Injection (or HTML Injection) it is also necessary to sanitize content that leaves the bank . I would focus my efforts on this, since their "symptoms" are not characteristic of a data entry / query problem (eg information leakage), but rather the output of the same.

  

Injection of files to backdoor

As far as my knowledge goes, this is not something that could be caused by bank failures, but rather the upload of files. A common situation is a site that allows images to be uploaded, but that only validates the file extension - not its content.

In this case, I do not have enough knowledge to give a guess, so I will not comment. The presence of a harmful file by itself does not seem to me sufficient to install a backdoor (for that it would also need some form of shell injection , but I'm not sure). But I can be quite wrong ...

P.S. I do not think it is related to your problem, but when I saw that your system used mysql_real_escape_string I got the flea behind my ear - although I can not guarantee anything. I suggest this post on security.SE for more details (read the comments also). At first, a correct and consistent use of this function should be good enough, but there are details to consider, for example the one that caught my attention:

  

I think the common misconception is that escaped values with mysql_real_escape_string are only meant to be used in a literal for MySQL strings . There are common cases where mysql_real_escape_string is used for data that is not put into a literal for strings, but for something else, type, such as an identifier, a keyword, a literal for integers, etc.

In your specific example I do not see this as a problem - because after using this function you still convert to int and check if it is numeric, so as far as I know in> (disclaimer: I have no experience with PHP) the vulnerability is not there. Anyway, check to see if there are any other uses for this function that might present problems.

    
16.09.2014 / 21:18
1

If you have no idea what exploit is being used, start with the lowest level layer: the database.

  • Identify the patterns . Do 'intrusions' always happen at the same time? Is there any similar content between records that affected? Is the source IP always the same?
  • Make a cleanup in the database based on the patterns found. (Beware of false positives.)
  • Create triggers that prevent the recording of records that match the patterns found in the database. Create a specific error code for this trigger.
  • Monitor your application and record all the pages where a call to the bank generated the error code you created.
  • Locate the fragile points used by exploit on the affected pages, and delete them.
16.09.2014 / 20:26