[fusion_builder_container hundred_percent=”no” hundred_percent_height=”no” hundred_percent_height_scroll=”no” hundred_percent_height_center_content=”yes” equal_height_columns=”no” menu_anchor=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” background_color=”” background_image=”” background_position=”center center” background_repeat=”no-repeat” fade=”no” background_parallax=”none” enable_mobile=”no” parallax_speed=”0.3″ video_mp4=”” video_webm=”” video_ogv=”” video_url=”” video_aspect_ratio=”16:9″ video_loop=”yes” video_mute=”yes” video_preview_image=”” border_size=”” border_color=”” border_style=”solid”][fusion_builder_row][fusion_builder_column type=”1_1″ layout=”1_1″ spacing=”” center_content=”no” link=”” target=”_self” min_height=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” background_color=”” background_image=”” background_position=”left top” background_repeat=”no-repeat” hover_type=”none” border_size=”0″ border_color=”” border_style=”solid” border_position=”all” padding_top=”” padding_right=”” padding_bottom=”” padding_left=”” dimension_margin=”” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=”” last=”no”][fusion_text columns=”” column_min_width=”” column_spacing=”” rule_style=”default” rule_size=”” rule_color=”” class=”” id=””]

I have been writing about penetration testing and its related skills for some time now but haven’t yet taken a good deep dive into web application penetration testing. In many ways, web application penetration testing is very similar to any other pentest, but there are some key differences and a few tools that are better suited to web application testing specifically.

One of the key differences between an external web application pentest and a typical internal pentest is the need for extra scrutiny on anything public facing. When I am conducting an internal pentest and find a “web server” running a slightly outdated version of SSL/TLS, I would rate that as a low impact, low severity finding. That exact same issue on a web server that has a public IP is much more severe and warrants a high severity rating. Before we dig into the other key differences let’s take a look at the constants.

What Remains the Same

The setup for a web application assessment is similar to that of any other system or network. You begin with the standard letter of engagement, which serves to outline the exact scope of the assessment. It also covers the pentester legally as the hacking itself ramps up. This is especially important because without proper permission many of the hacker’s actions are illegal. Once start dates and scope have been determined and all agreements signed, it is time to start with automated scanning.

All pentests, at least as I have always conducted them, begin with a basic vulnerability scan using a tool such as Qualys, Nessus, or OpenVAS. This gives the pentester a clear picture of where potentially vulnerable systems are on the target network. It takes some skill and knowledge to be able to decipher the scanner reports. Since software is rarely able to see the whole picture, the ratings and risk levels assigned are rarely accurate. However, a skilled ethical hacker will be able to quickly reassess the report. This allows them to downgrade and eliminate needlessly severe findings and do the opposite for findings that are falsely rated as low risk.

The penetration tester will then take the details from this scan and use that to piece together a plan of attack. This plan will often be a string of seemingly innocuous or low-level findings that when exploited in the right way will lead to a larger compromise. The end goal is the same for any type of pentest: find the major vulnerabilities before malicious attackers do and prove to the system or network owners that compromise of their most sensitive systems is possible.

How Does Web Application Penetration Testing Differ from Other Types?

When a web application is being assessed there is more than just the basic network infrastructure to test. In this instance, the pentester needs to look at all the related systems, be it their backend SQL databases or a Virtual Machine running in the cloud that brings the disparate connections and data together. Requiring the pentester to get access to the application from all (or at least good sampling) of the various access levels used in the real world is essential. Access to the various roles will allow the assessor to find flaws in the way the application is used. This helps reduce the risk of insider threat, which is a concern for many organizations. According to the Netwrix Cloud Security Report, “Almost 58% of organizations that had security incidents over 2017 blamed them on insiders.”

Beyond looking at the various access levels, it is important to understand the inner workings of the application. At a minimum, there should be a quick review of the application’s source code and a deep inspection of all related APIs. APIs are an often-overlooked security issue that affects most applications in some way. For one, most applications will use pre-made and trusted libraries to build out complex functions. To do this they often need to use API calls to link their code with the libraries needed. Third-party APIs will also be used regularly when the application needs to link to other applications or networking and security devices. For example, to send logs to the SEIM an API call might be used to exchange that information.

Finally, the issue that is most likely to cause issues, at least in the API arena, is the custom APIs we often see built for applications. When you consider that it is common for major vulnerabilities to be found in widely used and trusted APIs even with constant peer review, it is easy to see where a custom API will be at risk of far more potential issues.

Conclusion

If your organization is developing applications internally, simply performing an annual pentest is probably not enough to ensure your patients’ privacy and security. You should instead consider having a pentest that is focused on the application to avoid the common pitfalls that are inexorably tied to in-house application development.

[/fusion_text][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]