Discussion on the security of Open source Web program backstage

I. Preface

I do not know how recently Miss campus life, miss the canteen of fried rice. At that time will go to a variety of security BBS brush posts, like to see others write some of the security skills or experience of the summary; At that time BBS on a lot of article title are: Successful infiltration of XXX, successfully took xxx. Here is an invasion of a university in the Philippines article leads to the theme of the article, we first briefly look at the process. The university website uses the open source Web program called Joomla, (1) The youth uses a Joomla already exposes the loophole to enter the Web backstage (2) The youth uses the Joomla backstage uploads the restriction not to be strict flaw to upload a Webshell (3) controls the host to bestow our country national flag.

The original invasion of a host so easy, the administrator decisively to the Web program security patches. The administrator's work is over, as a security practitioner again to think is not Joomla backstage here can upload Webshell is not a problem, if Joomla backstage can not upload Webshell, it is not possible to reduce the possibility of invasion and loss. The following goes into the topic of this article: Web Daemon Security.

Ii. Introduction

Many domestic sites are based on Open source Forum, CMS built, such as Discuz, Phpwind, Dedecms and so on. These programs are the leader in the domestic open source Web program, but also pay more attention to security. Usually people pay attention to more is SQL injection, XSS these can directly steal user data vulnerabilities. Online because of the number of weak password intrusion cases, in addition to user data leakage events occur, relying solely on password protection backstage was broken, the possibility of social workers more and more. Get a management background password, combined with the background of arbitrary code execution, file inclusion or command injection, such as loopholes to get a shell, stealing user information is not difficult. At this time the security of the background program becomes a short board.

Discuz is a popular forum program, the author here to its background program for example, simple analysis of its security, the following directly to see some cases of vulnerability (DISCUZ latest version has been patched, please upgrade to the latest version of the user in time-discuz! X3.1 R20140101).

Iii. Case Studies

Tips: The $settingnew mentioned below is a variable that discuz the background store form data, which can be controlled by the backend user.

Case one: Improper user input data filtering logic

Vulnerability file: x3\source\admincp\admincp_setting.php

Analysis：

Case two: two injections

A brief introduction to two injections, the malicious user Alice in a place malicious data and stored in the database, in a does not directly lead to security issues; B refers to the data stored at a, triggering a security issue.

Vulnerability file: x3\source\admincp\admincp_setting.php

Analysis：

Case three: Vulnerabilities caused by new logic in program upgrades

Vulnerability file: x3\source\admincp\admincp_adv.php

Case FOUR: The bug patch is imperfect

Vulnerability file: x3\api\uc.php

Analysis：

The issue was publicly available as early as 2010 and the government issued a timely fix

For more information please refer to: http://www.oldjun.com/blog/index.php/archives/76/

Iv. Summary

These examples are mainly the author's practical experience of some of the summary, not necessarily comprehensive, hoping to give you some ideas; for example, the two injections mentioned above, $settingnew [' Seccodedata '] [' type '] This variable is not filtered, $ Other arrays of settingnew may not be filtered, and there are many similar problems, and you can try them on your own. There are two main directions for code auditing: (1) The risk function is traced up and (2) the user input is entered into the dangerous function; Dangerous functions here are mainly related to code execution: eval, Assert, file contains: include, require, etc. Command execution: System, EXEC, etc., write documents: fwrite, file_put_contents, etc.

Methods of code audit two articles are recommended here:

Https://code.google.com/p/pasc2at/wiki/SimplifiedChinese

Http://wenku.baidu.com/view/c85be95a3b3567ec102d8a12.html

V. Reflection

1, all input is harmful;

Background program user input compared to the foreground mainly increased background form data, in addition to some background support upload files (such as dz1.5 Custom sql), upload the contents of the file also belong to input; Must be strictly controlled and filtered.

2, safety awareness;

In fact, many of the loopholes are not caused by technical problems, but we lack of security awareness, do not pay attention to the security of the tragedy. The third and fourth, in particular, should not have happened at all; security advocacy and basic security training for developers.

3, loophole review;

(1) Developers receive vulnerabilities to summarize the causes of the vulnerability and review the code for similar problems. Sometimes developers just tinker with security personnel or white hat-provided vulnerabilities, and another code that has similar problems is not patched and continues to leak. This will also bring more hidden dangers, hackers are very willing and good at summing up the reflection, each patch is actually to the hacker to expand the idea, if the repair is not completely serious consequences.

(2) The security personnel needs to carry out the test confirmation after the developer patching completes, the above case four is the vivid example. In case of condition, security personnel should tidy up some common bug fix guidelines, this can also improve work efficiency.