AI in Application Penetration Testing: It’s Time to Go with the Flow - But Not Blindly

Artificial Intelligence is no longer a "good to have" in cybersecurity—it’s rapidly becoming a force multiplier. From solving complex challenges in CTFs to automating reconnaissance, exploitation, and even report generation, AI-driven penetration testing is demonstrating measurable promise.

But enterprise security is not a playground. It’s a controlled, high-stakes environment where assumptions can translate into real risk. As organizations begin to evaluate AI as a replacement—or augmentation—for human-led penetration testing, it’s critical to pause and ask the right questions.

• Is AI Penetration Testing Production Safe? - AI tools operate at speed and scale. Without strict guardrails, this introduces a real risk – unintended exploitation of live applications, service disruptions etc. Unlike human testers, AI does not inherently understand "safe boundaries" unless explicitly constrained.
• Is AI Only as Good as Its Prompter? – A prompt-orchestrated testing raises a fundamental dependency - the quality of findings is directly tied to the operator’s expertise. In effect, we may not be replacing human intelligence—we’re reshaping it.
• Can AI Replicate True Human Intelligence? - Some of the most critical vulnerabilities are not pattern-based—they are contextual (business logic flaws, privilege escalation chains etc.). These require situational awareness and integrated data flow understanding.
• Enterprise Reality: Integrated Application Ecosystems – In large enterprises, applications are interconnected - data flows across APIs, services, and third-party platforms. Security issues often emerge between systems—not within them. AI tools, unless specifically architected for this, may miss this integration.
• The False Positive Problem - AI can generate large volumes of findings quickly but is there still a need for manual triage? Are we shifting effort from "finding vulnerabilities" to "filtering noise"? Without a robust validation layer, organizations risk drowning in output with limited actionable intelligence.
• Data Privacy and Model Risk – AI thrives on data. By using AI penetration testers, are we risking data leakage and could this data be used to train third-party models? For many enterprises, this alone could be a blocker.
• Where Does the AI Pen Tester Sit in Your Network? - Deploying AI testing introduces architectural questions – does it require internet exposure? Is it deployed with full network access? What controls prevent lateral misuse if compromised?

The Way Forward: A Controlled, Measurable Approach

We are clearly at a turning point. AI in penetration testing is not a question of if—it’s a question of how and when. But premature adoption without structured evaluation can weaken, rather than strengthen, security posture. Organizations should resist binary thinking (AI vs Human) and instead focus on comparative validation:

• Conduct PoCs on real enterprise applications
• Benchmark AI-driven vs human-led testing
• Evaluate across:

• Depth of findings
• False positive rates
• Coverage of business logic vulnerabilities
• Time-to-deliver and cost efficiency 

AI is accelerating. Agent creation is becoming effortless. Automation is redefining scale. But security has never been about speed alone—it’s about precision, context, and judgment. We need to engineer the right balance between human intelligence and machine capability. 

We certainly should use AI in application security - it brings scale, speed, and the ability to uncover patterns that would otherwise take significant manual effort but the need of human intelligence cannot be completely written off. AI can accelerate discovery. Humans ensure relevance, accuracy, and real-world impact. Together, they create a security model that is not only efficient, but also resilient and trustworthy. Organizations that recognize this balance early will not just keep up with the shift—they will define it.

Article by Hemil Shah and Rishita Sarabhai 

Rethinking Mobile App Security: Importance of Client-Side Reviews

When organizations consider securing their mobile applications, the focus often remains server-side APIs. Ideally, this makes a lot of sense since APIs are a common attack surface, and in many cases, the same APIs are leveraged by both web and mobile applications. Security teams usually include these APIs thoroughly as part of web application assessments and penetration testing.

Another critical dimension when it comes to a mobile app architecture is the mobile client itself. A mobile application running on user devices introduce various risks, particularly around data storage & leakage - what data gets stored locally and how that data can be accessed. If we look at the three most common scenarios that make this critical: - 

1. Data Stored on the Client Side (On Mobile Device)
One of the most critical risks that organizations face unknowingly is what data is being stored on the device. If sensitive information such as authentication tokens, personal/PII data, or files with confidential information are cached insecurely, attackers with device access could exploit it.

2. Company-Owned Devices with Third-Party Apps
In some environments, companies use MDM (Mobile Device Management) solutions and disallow BYOD (Bring Your Own Device). Here, employees use only company issued devices, but organizations may still permit third-party applications. In such cases, every approved app release must be reviewed before deployment. Understanding what these apps store locally and whether they touch corporate data like emails/documents etc. becomes quite important.

3. Platforms and Marketplaces
Mobile applications often integrate deeply with an ecosystem when it comes to platform providers or marketplaces. These applications may access or even persist platform data on the device. Having zero visibility into how this data is handled, the risk of leakage grows significantly and can result in significant loss to marketplace providers.

The ever unsolved Local Storage Question
Across all these scenarios, one theme repeats: organizations need to know what is being stored locally and whether sensitive data is at risk.

In mobile applications, data isn’t always stored in plain text. Many applications use hashing, encoding, or even encryption which typically poses an identification challenge. While these methods may look like protection at first glance, they are not always implemented securely. In some cases: -

• Data might be encoded (e.g., Base64), but is easily reversible.
• Weak or custom encryption might give a false sense of security.
• Hashes might still leak valuable patterns or be vulnerable to brute force attacks.

When there is a large chunk of data in terms of device data or heavily loaded log files of the mobile application, manually identifying and validating sensitive data becomes extremely time consuming & inefficient. Due to his, it becomes crucial to introduce automated tools or scripts that can systematically find sensitive data in various storage formats.

A Quick Example
Consider a mobile application that saves the user's session token locally:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

This appears to be random text at first glance. It is actually a JSON Web Token (JWT) that is Base64-encoded. Due to this kind of encoding, anyone with access to the device can decode it and uncover: -  

{
  "user": "acme@acme.com",
  "role": "admin",
  "exp": "2025-08-31T23:59:59Z"
}

 
This shows that sensitive data, including roles, usernames, and token expiration dates, is being stored in local storage. If logs also capture this token (which happens more often than one can think), the exposure multiplies. Without automation, there is a high chance of missing out on spotting such patterns in logs.

Blueinfy’s Approach

At Blueinfy, we have taken a very focused approach to solving this problem. We developed a lightweight client-side mobile review framework that leverages internal technology and automation. Instead of duplicating heavy mobile product testing, our reviews target the most impactful risks:

• Sensitive Information stored in local storage
• Sensitive information left behind in logs (processed at scale using automation)
• Poor SharedPreferences usage and insecure storage practices
• Sensitive or private data sent to third parties

By combining automation scripts with targeted analysis, we can cut through massive logs, detect hidden storage of sensitive data, and flag cases where security controls (hash, encode, encrypt) don’t truly protect the data. The client-side mobile review framework is mainly developed keeping in mind the core problem of leakage of client/sensitive data.

Balancing Quality, Speed, and Cost
This approach allow us to achieve: -
•    High-quality insights: We focus on the areas that matter most.
•    Speed: In rapid agile cycles, automation enables quick reviews.
•    Cost-effectiveness: Real risks being addressed in a fraction of traditional mobile testing costs.

Final Thoughts
In today’s mobile first world, API security is only one part of the story. To truly protect organizational data, companies must also review the mobile client surface, with particular attention to how and where data is stored locally.

At Blueinfy, our approach shows that with the right focus and automation, organizations can uncover risks hidden in storage and logs without sacrificing quality, speed, or cost.

Article by Hemil Shah

The Importance of Security Reviews for Applications on Enterprise Platforms

As organizations increasingly rely on enterprise platforms like SharePoint, ServiceNow, Archer, Appian, Salesforce and SAP to develop critical applications, there is a common misconception that these platforms' built-in security features are sufficient to protect the applications from all potential threats. While these platforms indeed offer robust security mechanisms, relying solely on these features can leave applications vulnerable to various risks. Conducting a thorough security review is essential to ensure that applications remain secure, especially when customized configurations, third-party integrations, and the constant evolution of the threat landscape are considered.
 

Authorization Controls: The First Line of Defense
One of the primary security concerns in application development is ensuring proper authorization controls. Authorization determines what actions users are permitted to perform within an application and which data they can access. Enterprise platforms provide default authorization mechanisms, but organizations often need to customize these controls to meet specific business requirements. Customizations may involve defining unique user roles, permissions, and access levels that deviate from the platform's standard configurations. However, such customizations can introduce vulnerabilities if not implemented correctly.

For example, poorly configured authorization controls might enable unauthorized users to access sensitive data or carry out critical actions beyond their designated privileges, leading to data breaches, regulatory violations, and potential damage to the brand. A comprehensive security review is essential to detect and address any flaws in the authorization setup, ensuring that users are restricted to the information and functions relevant to their roles.
 

Logical Flaws: The Hidden Dangers in Business Logic
Business logic is the backbone of any application, dictating how data flows, how processes are executed, and how users interact with the system. However, logical flaws in business processes can lead to significant security vulnerabilities that are often overlooked. These flaws might allow attackers to bypass critical controls, manipulate workflows, or execute unintended actions, all of which could have serious consequences.

For example, in an application developed on a platform like Archer, a logical flaw might allow a user to bypass an approval process and gain access to confidential documents without the necessary authorization. Such vulnerabilities can be difficult to detect through traditional security measures, as they do not involve technical exploits but rather exploit weaknesses in the business process itself. A security review that includes thorough testing of business logic is essential to uncover and address these flaws, thereby safeguarding the integrity and functionality of the application.
 

Zero-Day Vulnerabilities: The Ever-Present Threat
No platform, regardless of its security features, is immune to zero-day vulnerabilities—previously unknown security flaws that can be exploited by attackers before the platform provider releases a patch. These vulnerabilities represent a significant threat because they are often exploited quickly after discovery, leaving applications exposed to attacks.

Even though enterprise platforms like SharePoint and SAP are routinely updated to address known vulnerabilities, zero-day threats can still present significant risks to applications. Organizations need to remain vigilant in detecting potential zero-day vulnerabilities and be ready to respond quickly to any new threats. Incorporating vulnerability assessments and regular security updates into the security review process is critical for minimizing the risks associated with zero-day vulnerabilities.
 

Customization and Configuration: The Double-Edged Sword
One of the primary reasons organizations choose enterprise platforms is the ability to customize applications to meet their unique business needs. However, customization and configuration changes can introduce significant security risks. Unlike out-of-the-box solutions, customized applications may deviate from the platform's standard security practices, potentially exposing vulnerabilities that would not exist in a standard configuration.

For example, a seemingly small change in a SharePoint configuration—like modifying default permission settings or enabling a feature for convenience—could unintentionally create a security gap that attackers might exploit. Furthermore, custom code added to the platform often lacks the rigorous security testing applied to the platform itself, heightening the risk of introducing new vulnerabilities. Conducting a thorough security review that evaluates all customizations and configurations is crucial to ensuring these changes don’t compromise the application’s security.
 

Integration with Third-Party Systems: Expanding the Attack Surface
Modern applications often require integration with third-party systems to enhance functionality, whether for user authentication, data analytics, or front-end services. While these integrations can provide significant benefits, they also expand the attack surface, introducing new security challenges that must be addressed.

For example, integrating a third-party single sign-on (SSO) service with a ServiceNow application can simplify user access management but also creates a potential entry point for attackers if the SSO service is compromised. Similarly, integrating external data analytics tools with an Appian application may expose sensitive data to third parties, increasing the risk of data breaches. A security review that includes thorough testing of all third-party integrations is vital to identify and mitigate these risks, ensuring that data is securely transmitted and that external services do not introduce vulnerabilities.
 

Unpatched or Outdated Versions: A Persistent Risk
Running outdated or unpatched versions of an enterprise platform or its integrated components is a common yet significant security risk. Older versions may contain known vulnerabilities that have already been exploited in the wild, making them prime targets for attackers. Even if the platform itself is kept up to date, third-party plugins, libraries, or custom components may lag behind, creating weak points in the application's security.

Regular security reviews should include a comprehensive audit of all components used in the application, ensuring that they are up to date with the latest security patches. Additionally, organizations should implement a proactive patch management process to address vulnerabilities as soon as patches are released, reducing the window of exposure to potential attacks.

Conclusion: The Necessity of Continuous Security Vigilance
In today’s complex and rapidly evolving threat landscape, relying solely on the built-in security features of enterprise platforms is insufficient to protect applications from the myriad risks they face. Whether due to customizations, third-party integrations, or emerging vulnerabilities, applications on platforms like SharePoint, ServiceNow, Salesforce, Archer, Appian, and SAP require continuous security vigilance.

This is where the expertise of a company like Blueinfy becomes invaluable. Having performed numerous security reviews across these platforms, Blueinfy possesses deep insights into where vulnerabilities are most likely to lie. Their extensive experience allows them to pinpoint potential risks quickly and accurately, ensuring that your application is thoroughly protected. By leveraging Blueinfy’s knowledge, organizations can significantly reduce the likelihood of security breaches, protect critical business applications, and maintain compliance with regulatory requirements. Blueinfy’s ability to identify and mitigate risks effectively adds substantial value, safeguarding not just data and processes, but also the organization’s reputation in an increasingly security-conscious world.

Article by Hemil Shah

[Case Study] Enhancing Security in a Large Manufacturing Company's Applications

Background
A large manufacturing company, managing a wide array of applications critical to its operations, engaged a US-based ACME company having a DAST scanner to conduct a security assessment. ACME utilized it’s proprietary automated scanner to identify vulnerabilities across the company’s applications. However, during the assessment, ACME realized that while their scanners were effective in detecting standard vulnerabilities, they had limitations in identifying more complex issues, such as logical abuses and authorization bypasses—risks that could severely compromise the security of the company’s applications.

Challenge
The primary challenge was the inability of automated scanners to detect critical vulnerabilities related to business logic and authorization controls. These types of vulnerabilities require a deep understanding of the application’s functionality and how users interact with it, which often falls outside the capabilities of an automated scanner. The manufacturing company needed a more thorough approach to ensure that these high-risk issues were addressed and that their applications were secure.

Solution
Recognizing the limitations of their automated scanner, ACME sought the expertise of Blueinfy, a specialized security firm with extensive experience in uncovering complex vulnerabilities. Blueinfy proposed a targeted, time-bound manual penetration testing approach focused specifically on identifying authorization bypasses and logical abuses. Blueinfy’s team of skilled security professionals conducted in-depth manual testing of the manufacturing company’s applications. This method allowed them to simulate real-world attacks, exploring the applications' business logic, user roles, and access controls in a way that automated scanner could not.

Combining manual penetration testing with automated scans offered a balanced and comprehensive approach to security assessments specially in a scenario of large application assets. Here are some key benefits of this engagement to manufacturing company - 

1. Coverage and Depth
Scanner quickly scanned and identified common vulnerabilities across large systems, covering a wide range of issues efficiently. Scanners are great for routine checks and can handle repetitive tasks without getting tired. Manual testing explored vulnerabilities that automated scanner might miss, particularly those that require contextual understanding or nuanced analysis, such as business logic flaws, complex access control issues, and custom applications.
2. Efficiency and Thoroughness
Scanner helped in accelerating the process by identifying obvious vulnerabilities, which can then be reviewed and validated by manual testers. This saved time compared to manual testing alone. Manual Testing ensured that the identified vulnerabilities are accurately validated and assessed, reducing false positives and ensuring that the results are actionable.
3. Cost-Effectiveness
Scanner reduced the overall cost of initial assessments by handling the bulk of routine checks. Manual Testing focused on high-value areas where human insight is crucial, optimizing the cost associated with expert time.
4. Adaptability
Scanner were configured and run at regular intervals, providing ongoing assessments and alerts for newly discovered vulnerabilities. Manual Testing adapted to the specific context of the application and its environment, adjusting tactics based on findings and changing threat landscapes.
5. Comprehensive Reporting
Scanner generated detailed reports with identified vulnerabilities, often with recommendations for remediation. Manual Testing provided in-depth analysis and contextual information that enhances the automated reports, offering insights into the impact and potential exploitability of vulnerabilities.
6. Continuous Improvement
Scanner continuously updated to detect new vulnerabilities and threats as they emerge. Manual Testing allowed for human intuition and understanding of emerging threats, contributing to a more nuanced security posture.

Outcome
The manual penetration testing approach recommended by Blueinfy proved to be highly effective. Blueinfy team identified critical authorization bypasses or logical abuses in more than 98% of the applications tested. The combination of manual testing, with its focus on high-risk areas, and the automated scanning provided a comprehensive assessment that uncovered a significant number of vulnerabilities that could have otherwise gone undetected.

As a result, the manufacturing company was able to address these vulnerabilities, significantly enhancing the security of their application assets. The collaboration between Blueinfy and ACME not only improved the manufacturing company’s overall security posture but also demonstrated the value of integrating manual and automated testing methods. By partnering with Blueinfy, ACME ensured that even the most complex and subtle vulnerabilities were identified and mitigated, safeguarding operations and reducing the risk of potential security breaches of the client applications.

In essence, using both manual and automated penetration testing approaches leverages the strengths of each, leading to a more robust and effective security assessment.

Article by Hemil Shah

[Case study] Agile Product Company Balances Rapid Release Cycles with Security

Background
A product company utilizing agile methodology was grappling with the challenge of ensuring robust security while managing frequent sprint release cycles. The company managed their sprint stories as part of a ticketing system. The company’s commitment to both speed and security led them to engage Blueinfy to ensure security without compromising deployment timelines. The goal was to integrate security seamlessly into their agile development process.

Challenge
The company’s agile development model involved rapid, iterative releases, which posed a challenge for maintaining comprehensive security assessments. The primary need was to align security testing with their fast-paced development cycle without impeding the release schedule. 

Solution
Blueinfy developed a strategic security approach tailored to the company’s agile workflow, leveraging agile penetration testing principles:

Initial Comprehensive Penetration Test
To establish a security baseline and identify pre-existing vulnerabilities before the agile release cycles commenced, Blueinfy conducted an in-depth penetration test to assess the application’s security posture comprehensively. This initial assessment provided a detailed report outlining vulnerabilities, their potential impacts, and remediation recommendations.

Ongoing Agile Penetration Testing
 To continuously assess the security implications of changes in each agile release cycle. The company shared an export from their ticketing system in excel format with Blueinfy, detailing use cases, changes, and user stories associated with each release. Blueinfy team, having complete knowledge of the application and security knowledge, identified the changes which can potentially have a security impact. Blueinfy team performed targeted penetration tests focused on the specific changes highlighted. This approach, aligned with agile testing practices, allowed for rapid assessments of security impacts without disrupting the development cycle. Blueinfy integrated into the company’s agile workflow, providing quick feedback on vulnerabilities introduced by new changes. This iterative process ensured that security assessments were aligned with the pace of development.

Enhanced Reporting and Management Tracking
To enable effective tracking and management of security performance, Blueinfy delivered detailed reports on vulnerabilities, trends, and the status of issues, which were updated regularly to reflect the latest changes. A security dashboard was developed, offering management a clear, real-time view of the application’s security status, including trends and actionable insights. As an example, following graph was provided: -
 

The iterative nature of testing allowed for continuous improvement and adaptation of security practices in response to evolving threats and development changes.
Benefits

• Security assessments were integrated into the agile development process, allowing for rapid and efficient identification of vulnerabilities without slowing down release cycles.
• Detailed and timely reports enabled management to track security performance, prioritize remediation efforts, and make informed decisions.
• The targeted approach ensured that each release was evaluated for security impacts in the context of recent changes, aligning with agile principles and enhancing overall security posture.
• Blueinfy’s agile penetration testing approach fostered close collaboration between security experts and development teams, facilitating a proactive and adaptive security strategy.

Key Differences

Conclusion
By leveraging Blueinfy’s agile penetration testing expertise, the company successfully balanced the need for rapid release cycles with robust security measures. This approach not only streamlined their security assessments but also ensured that security remained a key focus throughout their agile development process, enhancing both speed and security in their product releases.

Article by Hemil Shah

Securing Legacy SaaS Accounting Software: A Comprehensive Review and Remediation

Client Overview
A rapidly growing company offering accounting software as a SaaS expanded its platform by adding features such as custom reports, cloud integrations, and API support. The platform, however, was built on legacy PHP code, and the traditional development approach, along with complex customizations, led to numerous security issues that were difficult to prioritize and resolve.

Challenges

• The platform was built on outdated PHP code, which made it prone to security vulnerabilities.
• The rapid addition of features introduced multiple layers of complexity, increasing the risk of security flaws.
• The existing development process lacked modern security practices, resulting in a backlog of security issues that were hard to address and prioritize.
• The company struggled to identify and fix security vulnerabilities efficiently, especially those related to input validation, output encoding, injections, and file uploads.

Blueinfy's Approach
To address these challenges, Blueinfy proposed a combined manual black-box testing and code review approach using their in-house tools. This approach was tailored to the specific needs of the legacy PHP environment and focused on identifying and resolving critical security issues.

1. Comprehensive Product Understanding
Blueinfy’s team took the time to thoroughly understand the product, its architecture, and the existing security measures in place. This deep understanding allowed them to tailor their approach to the unique challenges of the platform.
2. Manual Black-Box Testing
The team conducted manual black-box penetration testing to simulate real-world attack scenarios. This testing was aimed at uncovering security vulnerabilities without prior knowledge of the internal code, focusing on areas like input validation, output encoding, and file uploads.
3. In-Depth Code Review
Parallel to the black-box testing, Blueinfy’s code review team analyzed the PHP codebase to trace the root causes of the issues identified. The review focused on common security concerns such as SQL injection, cross-site scripting (XSS), and improper data handling.
4. Correlation of Findings
The code review team correlated the results from the black-box tests with the underlying code issues, identifying common root causes and providing targeted recommendations for remediation.

Results
The combined approach led to the identification of several high-severity vulnerabilities that were previously overlooked or not fully understood. Blueinfy delivered a detailed report that highlighted these findings and provided clear, actionable recommendations for fixing them.

• The report prioritized the most critical security issues, enabling the client to focus on what mattered most.
• Blueinfy’s recommendations were tailored to the legacy PHP environment, ensuring that the fixes were both effective and feasible to implement.
• The client implemented the suggested fixes, resulting in a significantly more secure application.

Conclusion
Blueinfy’s combined manual black-box and code review approach provided the client with a clear path to securing their legacy PHP-based accounting software. By focusing on both the surface-level vulnerabilities and their underlying causes, Blueinfy helped the company address critical security issues, ensuring the platform was robust and secure for its users.

Article by Amish Shah

Attack Surface analysis and Entry Point Identification

Each web application is running with possible attack surface. Attack surface is defined by number of attack points it contains. Attack surface exposure is cut across various component of application like web server, application server, database etc. As shown in figure 1 we have browser accessing application over Internet. Browser contains various different set of technologies and accessing application as client. It directly access application server over HTTP. Application page is integrated in backend infrastructure like database and authentication servers. At the same time application is not working in isolation so it accesses other information using APIs.

Figure 1 – Attack Surface

Here attack surface contain following elements

1.) Application server pages and access
2.) Database and Authentication modules
3.) Browser access variables for client side attacks
4.) Stream or data coming from web services / APIs

Web application modules and pages will access information coming from various sources and let’s see range of possible entry points. As shown in figure 2 we can have range of possible entry points to the system both on server and client side.

Figure 2 – Entry points on attack surface

Entry points

Web or application pages consume HTTP requests and process incoming values. All these variables become entry points or source to the system. Let’s look at them in detail.

Querystring as an entry point

Each incoming HTTP request can pass on values through querystring to web/application pages. Here is an example

http://example.com/login.aspx?username=shah

In above case we have name value pair username & shah is passed as HTTP parameter to application page called login.aspx. If we look at actual HTTP request then it would look like following.

GET /login.aspx?username=shah HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

It is GET request hitting to application pages along with some other HTTP headers. All these headers and name-value pair get processed by web pages.

POST-Name/Value pair as query string

We have passed value using GET request by querystring in above case, it is also possible to pass similar value by POST request where size of value can be unlimited. In querystring one can pass maximum buffer of 256 characters only. For example here is simple POST request

 POST http://example.com/cgi-bin/search.cgi HTTP/1.1
 Host: example.com
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10
 Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, text/plain;q=0.8, image/png, */*;q=0.5
 Keep-Alive: 300
 Referer: http://example.com/
 Content-Type: application/x-www-form-urlencoded
 Content-Length: 17

 search=searchtext

As you can see as an entry point buffer or content-length of 17 passed and its value would be search=searchtext. This is another potential entry point for web applications. Querystring and POST-name/value pairs are most common entry points get abused by attacker.

HTTP Variables/Headers

We have seen both GET and POST requests in above cases. As you can see along with name value pair we need to pass several other HTTP headers like referer, content-type, accept etc. There are list of possible HTTP requests which are define in RFC to be processed by web server. Some of these values get accessed by web pages as input and it becomes entry points to the system as well.

Here is a list of header for HTTP by RFC – http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.22

It is possible to abuse these headers and launch attack against the target application.

XML/SOAP/JSON streams (Web 2.0)

Traditional applications were using name-value pair approach with GET or POST requests but with Web 2.0 applications we are seeing several new ways of communicating various different structures and protocols all over HTTP. All these new streams and protocol can be considered as new entry points to the application and one needs to identify them in source code.

Here are some important different entry points with respect to Web 2.0 or non name-value pair based entry points.

XML-RPC – RPC (Remote Procedure Call) is very old concept to invoke procedures remotely. These remote calls were for underlying operating system which can be invoked from same machine or over the network. Over period to defend operating system some of the ports were closed and only available open ports were 80 and 443. These ports are supporting HTTP protocol only. This opens a demand for RPC running on HTTP. This need was addressed by XML-RPC. Specification for XML-RPC is found at http://www.xmlrpc.com/spec.

Example,

POST /trade-rpc/getquote.rem HTTP/1.0
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: xmlrpc.example.com
Content-Type: text/xml
Content-Length: 161

<?xml version="1.0"?>
<methodCall>
<methodName>stocks.getquote</methodName>
<params>
<param><value><string>MSFT</string></value></param>
</params>
</methodCall>

In above case “MSFT” holding place can be entry point to the application.

SOAP – SOAP (Simple Object Access Protocol) message is known as SOAP envelope and it gets exchanged between server and client. SOAP has specific skeleton for information exchange.

Example,

<?xml version="1.0" encoding="utf-8"?>
   <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
                           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
                           xmlns:xsd="http://www.w3.org/2001/XMLSchema">
      <soap:Body>
         <getQuotes xmlns="http://tempuri.org/">
            <compid>MSFT</compid>
         </getQuotes>
      </soap:Body>
   </soap:Envelope>

Again over here as well one can inject values into various part of SOAP message as well.

REST – REST(Representational State Transfer) REST is a modern Web application architecture style. It can fall in SOA as well. REST uses XML structures to communicate between client and server and vice a versa.

Example,

<?xml version="1.0"?>
<p:Laptops xmlns:p="http://laptops.example.com"
xmlns:xl="http://www.w3.org/1999/xlink">
<Laptop id="0123" xl:href="http://www.parts-depot.com/laptops/0123"/>
< Laptop id="0348" xl:href="http://www.parts-depot.com laptops /0348"/>
< Laptop id="0321" xl:href="http://www.parts-depot.com/ laptops /0321"/>
…
…
</p:Laptops>

In this case it is possible to inject values into XML nodes.

JSON – JSON (JavaScript Object Notation) is very light weight format for data exchange. JSON is getting popularity with developers for Web 2.0 applications. JSON is supported by various languages and scripts so it is easy to integrate and becoming very popular as well.

Example,

{"bookmarks":[{"Link":"www.example.com","Desc":"Interesting link"}]}

In this case JSON structure can be manipulated and corresponding values can be injected. All different values in JSON can act as potential entry point to the application.

Similarly on same line we can have JS-Objects as well,

message = {
    from : "john@example.com",
    to : "jerry@example.com",
    subject : "I am fine",
    body : "Long message here",
    showsubject : function(){document.write(this.subject)}    
};

Some of the platforms are using customized structures for information transfer like below.

{names:{“name-a”:”John”,”name-b”:”Jack”}}

Some of the developers are passing information in simple XML as well and again that become entry points as well. If application is utilizing some sort of frameworks then there is abstraction and framework will convert XML stream into respective values at intermediate level. It is interesting to capture these calls as well.

File Uploads

 Different applications are allowing uploading files to the application and it is possible to load malicious file to the target application. These files can create several different issues for the application and can be exploited as well.

For example, forms are multipart as shown below.

<form name="Form1" method="post" action="ContractUpload.aspx" id="Form1" enctype="multipart/form-data">

It is taking input as file as below,

<input name="uplTheFile" type="file" id="uplTheFile" />

Files can be attached with some advanced protocol as well like SOAP or can be posted directly over WebDAV as well. All these combinations open up new possible entry points to the application.

Feeds, third party information and APIs

 As shown in our initial figure (1) where we have seen modern days applications are consuming information from various different sources using APIs. For example, Google has published their JSON RPCs to access google database over HTTP for search results. If an application wants to integrate then can use this APIs and can make a call. This information get injected into server side code. This can be considered as entry point as well. RSS/ATOM feeds are another set of information source or entry points to the application.

Example,

<rss version="2.0">
  <channel>
    <title>Example News</title>
    <link>http://example.com/</link>
    <description>News feed</description>
    <language>en-us</language>
    <pubDate>Tue, 10 Jun 2006 04:00:00 GMT</pubDate>
    <lastBuildDate>Tue, 10 Jun 2006 09:41:01  
        GMT</lastBuildDate>
    <docs>http://example.com/rss</docs>
    <generator>Weblog Editor 2.0</generator>
    <item>
      <title>Today's title</title>
      <link>http://example.com/10thjune.asp</link>
      <description>News goes here</description>
      <pubDate>Tue, 03 Jun 2006 09:39:21 GMT</pubDate>
      <guid>http://example.com/news.html#item300</guid>
    </item>
      ...
    </item>

All different values of RSS nodes can be manipulated and injected as well.

We have discussed several different entry points in above section. Some of them are valid for clients as well. The part of application is going to run on browser and browser can have following entry points. In with stream are coming into browser and if malicious payload gets injected in the HTML then can cause XSS or any other breach.

1.) HTTP response – All headers as well as HTML content
2.) JavaScripts coming from server
3.) Ajax/RIA calls consuming different structures which we have discussed like JSON, XML, JS-Object etc.
4.) Callbacks – Modern days applications are using callback mechanism so data coming from browser can be injected into DOM using script functions.
5.) Browser making API calls across domains

All these are entry points and now we need to identify their position in our source code. If we can identify all possible entry points in our system then it can help greatly in reducing attack surface. If complete source code is of 35,000 lines and if we can find 30 lines of entry points then now we know where we should be focusing for our analysis.