Why a Web Application Pentest?

In a previous post, we discussed the basics of the Web application security: the most common vulnerabilities and attacks, as well as some mitigation techniques.

From what we've talked about so far, we can safely conclude that we need to be thinking about the Web application security on every stage of the application development - from the technical design, through the testing and implementation to the post implementation period.

Computer security is commonly categorized in four functional groups: risk avoidance, prevention, detection, and response and recovery. To have all these, organizations need to assess their level of security; that is where the penetration test can play a crucial role. Of course, to achieve its goal, the penetration test should be done correctly.

Some security researchers passionately defend the need of a penetration test, others argue that the organizations just spend a lot of money to measure the skills of the testers. In this post, I will try to present a somewhat non-standard approach to understanding what a penetration test is and why an organization would want to do penetration tests.

The Penetration Testing Report

So, the fun you had hacking a web application is over, and you need to start writing the final report. You start wondering where to start, how to structure it, format it, and how to make it look good.

We will try to answer all that in this post. For this purpose, we will see how to write a Final Report on a Web application penetration test.

When Bad Things Start to Happen (Part II – Linux)

We have previously blogged about what information to collect from a Windows box when we suspect that it has been compromised. Now, we will discuss what information we can get from a Linux system without launching a full-blown forensic investigation.

Generally, the logic is the same - we will be searching for the attack vector; modifications on the system, resulting in persistence;  unusual processes and commands; and changes in the system environment. We would still need to get the information from the network level as described in the previous post.

When Bad Things Start to Happen (Part I – Windows)

Sooner or later, everyone has to deal with a device that has been compromised, or there is a strong reason to believe that it has been compromised. Incident response is just as important as the security design of the network architecture, the regular security assessment tests, and the secure coding.

We will not try to cover the stages of the Incident Response process though; there is extensive documentation about this on the Internet. Rather, what we will try here is to summarize what information we need to collect from the supposedly compromised machine for analysis.

The MySQL Month

The month is not over yet,  but with the end of the world approaching, we may safely say that this month is the month of MySQL bugs (or features). Kingcope published seven MySQL vulnerabilities in the first weekend of the December, which made quite the buzz in the security community. In this post we will […]

Another 0-day in IE

This can easily be the quarter of MSIE bugs. Yet another vulnerability in Internet Explorer has been found, and of course, there is a Metasploit module for it.