Web Application Hacking: Exposing Your Backend
by Peter Wood - Chief of Operations for First Base Technologies - Tuesday, 11 November 2003.
Known (published) vulnerabilities in web servers are obviously a great source of risk, but perhaps the most easily defended against by patching. The difficulty comes from having to install patches on many servers. Streamlined patching procedures are essential, as are server inventories. If a patch is missed, a hacker will let you know!

Administrative issues are less easily corrected than published vulnerabilities. This requires a security awareness in those who manage the web site and its content on a daily basis. Clearly directory browsing should not be enabled anywhere, and the correct access control lists (ACLs) applied to every directory and file. This is more than just configuration, the implication of content is critical too. For instance, remnant files such as "readme.txt" or sample applications can reveal the applications and versions in use. Of course, commercial applications have known vulnerabilities too, just like web servers and operating systems. Backup files or improper application mapping can reveal source code, including the information necessary to connect to the database.

The application logic itself must be careful constructed and must include security mechanisms. Input should never be assumed to be what was expected. It must be tested, validated, and filtered. Applications that call up files, especially directly from the file system, must be carefully checked. Its too easy to expose source code, or worse yet, system files. Anything that even resembles javascript or vbscript must be removed. Inadvertently storing scripts entered by a hacker will allow them to be replayed against customers, resulting in the web site attacking customers or divulging session information to the hacker. All error messages must be handled. Unhandled (raw) error messages are a roadmap through the application and database. Database calls must be structured carefully, and any user input that will used in the query must be scrutinised. Carefully constructed input could allow a hacker to piggy-back legitimate queries with their own, giving them access to the database through the web application.

Security throughout

The management of web application vulnerabilities must occur in several different areas.

Security must be brought to the web development team. Create and enforce secure coding practices. Assess the code while its being developed, to identify insecure techniques before they are replicated. Ensure that QA test for security as well as functionality. Think security during change control procedures - don't consider just the functional and performance impact of changes, consider the security impact as well.

The security department must learn application security. Create and promote internal awareness campaigns. Work with the development team to develop and publish best practices, and enforce those best practices. Create procedures to work with development to remediate vulnerabilities. Audit production systems frequently and with each change. Baseline and trend the results to gain a historical perspective of application security. Implement web application security assessments into Certification and Assessment programmes. Most importantly, assess applications in depth. Ensure the security is 'baked-in', not 'brushed-on'.

Automated assessment tools can help introduce and maintain security throughout the application life cycle. Best of breed tools include: WebInspect from SPI Dynamics, AppScan from Sanctum and ScanDo from KaVaDo.


Harnessing artificial intelligence to build an army of virtual analysts

PatternEx, a startup that gathered a team of AI researcher from MIT CSAIL as well as security and distributed systems experts, is poised to shake up things in the user and entity behavior analytics market.

Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.

Daily digest

Receive a daily digest of the latest security news.

Mon, Feb 8th