Try : Insurtech, Application Development

AgriTech(1)

Augmented Reality(21)

Clean Tech(9)

Customer Journey(17)

Design(45)

Solar Industry(8)

User Experience(68)

Edtech(10)

Events(34)

HR Tech(3)

Interviews(10)

Life@mantra(11)

Logistics(6)

Manufacturing(5)

Strategy(18)

Testing(9)

Android(48)

Backend(32)

Dev Ops(11)

Enterprise Solution(33)

Technology Modernization(9)

Frontend(29)

iOS(43)

Javascript(15)

AI in Insurance(41)

Insurtech(67)

Product Innovation(59)

Solutions(22)

E-health(12)

HealthTech(25)

mHealth(5)

Telehealth Care(4)

Telemedicine(5)

Artificial Intelligence(154)

Bitcoin(8)

Blockchain(19)

Cognitive Computing(8)

Computer Vision(8)

Data Science(24)

FinTech(51)

Banking(7)

Intelligent Automation(27)

Machine Learning(48)

Natural Language Processing(14)

expand Menu Filters

[Part 2] Web Application Security Testing: Top 10 Risks & Solutions

By :
7 minutes, 29 seconds read

In the previous article, we discussed risks and web application security testing measures for 5 types of attacks-

  1. Injection
  2. Broken authentication and session management
  3. Cross-site scripting
  4. Indirect object security reference
  5. Security misconfiguration

Link – Part 1

Now let’s continue with the remaining 5 web application security threats.

6. Sensitive data exposure

Broken authentication and inefficient session management leads to sensitive data exposure. Examples of applications vulnerable to sensitive data exposure.

  • Data stored in plain text, such as passwords or credit card data 
  • Lack of HTTPS on authenticated pages
  • Hashed passwords with lack of salt, making the password easily cracked
  • Tokens disclosed in public source code
  • Browser header caching sensitive data

I would suggest going through the part 1 of this series for in-depth knowledge about this vulnerability.

7. Cross-site forgery

Cross-Site Request Forgery (CSRF) or session riding- attacks, an attacker forces a victim to make an inappropriate web request such as a fraudulent bank transaction. For example, an attacker tricks the victim client into calling a banking function in a vulnerable page that transfers money from the victim’s to the attacker’s account. The victim triggers the attack by following an attacker’s link or visiting an attacker’s page. The vulnerable server page doesn’t recheck the authenticity of the victim’s request and allows proceeding the transfer.

The following steps detail the anatomy of a CSRF attack:

  1. The attacker finds a functionality in a web application that is vulnerable to CSRF.
  2. Attacker builds a link invoking the vulnerable function and by passing the required parameters, executes the attack.
  3. The Attacker then waits until the victim client authenticates with the vulnerable web application.
  4. Attacker tricks the victim client into following the malicious link.
  5. Victim client sends a forged request to a vulnerable server.
  6. Vulnerable server allows and executes the forged request.

For example, the link might look like this when the payload is to transfer money from the victim’s to the attacker’s account:

/makeTransfer?amount=1000&dest=attacker@attackersite.com

The following link sends an email titled ‘Hello’ to johny@example.com – 

/sendMail?to=johny@example.com&title=Hello&body=I+did+not+send+this

Basic test for cross-site request forgery

You can follow these test steps to test against CSRF bugs-

  1. Find a web application page that triggers/performs an action upon user request.
  2. Construct a page containing a link or redirect that sends a forged request to the application server. This link usually contains a tag such as an img or iframe with the source address pointing to the request.

<a href=”http://bank.com/transfer.do?acct=MARIA&amount=100000″>View my Pictures!</a>

<img src=”http://bank.com/transfer.do?acct=MARIA&amount=100000″ width=”1″ height=”1″ border=”0″>

  1. Note that the links above will generate a GET request. In order to test for POST requests you must create a page containing a form with the URL parameters passed as hidden input, and add a script to automatically submit the form:
 <form action=”http://bank.com/transfer.do” method=”post”>
     <input type=”hidden” name=”acct” value=”MARIA”>
     <input type=”hidden” name=”ammount” value=”100000″>
</form>
<script>
     document.forms[0].submit();
</script>
  1. Open an Internet browser and log in to the web application as a legitimate user.
  2. Open the page built in step 2 (follow the link if necessary).
  3. Confirm if the request was successful.
  4. Repeat test case for every application create/update/delete/mail action.

Expected result: the test fails if the application trusts and processes the forged request.

Also, attackers can manipulate cookies.

Another example,

Suppose, we allow users to post images on our forum. What if one of our users post this image?

<img src= “http://foo.com/logout”>

This is not really an image. But, it will force the target URL to be retrieved by any random user who happens to browse that page — using their browser credentials! From the webserver’s perspective, there is no difference whatsoever between a real user initiated browser request and the above image URL retrieval.

If our logout page was a simple HTTP GET that requires no confirmation, every user who visits that page would be immediately logged out.

Consider these examples of cross-site forgery: CSRF token leakage through Google Analytics, deleting account and erasing imported contacts, change any user ZONE, Add optional two factor mobile number

8. Missing function level access control

If the authentication check in sensitive request handlers is insufficient or non-existent, the vulnerability is Missing Function Level Access Control.

How to test for missing function level access control?

The best way to find out if an application fails to properly restrict function level access is to verify every application function-

  1. Does the UI show navigation to unauthorized functions?
  2. Are server side authentication or authorization checks missing?
  3. Are server side checks solely rely on information provided by the attacker?

Using a proxy, browse the application with a privileged role. Then revisit restricted pages using a less privileged role. If the server responses are alike, the My Organization application is probably vulnerable.

In one potential scenario an attacker simply forces the browser to target URLs. Consider the following (non-My Organisation) URLs which should require authentication. One also requires admin rights to access the “admin_getappInfo” page.

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

If a non-authentic user (attacker) gets access to either page, then it means — unauthorized access was allowed. This flaw may lead the attacker to access more unprotected admin pages.

Example of missing function level access control atack – Delete Credit Cards from any Twitter Account.

9. Shellshock and Heartbleed attacks

Shellshock

It is a remote command execution vulnerability in Bash. A series of random characters, () { :; }; , confuses Bash because it doesn’t know what to do with them, so by default, it executes the code after it.

More on — manually exploiting shellshock vulnerability

Tools for checking Shellshock

Through command line:

To determine if your Linux or Unix system is vulnerable, type the following in the command line-

 env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”
If the system is vulnerable, the output will be:
 vulnerable
 this is a test
 An unaffected (or patched) system will output:
 bash: warning: x: ignoring function definition attempt
 bash: error importing function definition for `x’
           this is a test

Online tools – 

  1. Penetration testing tools
  2. Shellshock bash vulnerability test tool

Heartbleed

It is a critical bug in OpenSSL’s implementation of the TLS/DTLS heartbeat extension. It allows attackers to read portions of the affected server’s memory, potentially revealing users data, that the server did not intend to reveal.

An attacker can trick OpenSSL into allocating a 64KB buffer, copy more bytes than is necessary into the buffer, send that buffer back, and thus leak the contents of the victim’s memory, 64KB at a time.

Web application security testing tools for heartbleed attack

  1. defribulator v1.16 : Command→ python ssltest.py example.com (ssltest.py file is available with me)
  2. Online tool: Filippo
  3. For android, you can download Bluebox open SSL scanner

Also read – Heartbleed bug FAQs, Bugs and solutions

How to prevent heartbleed attack?

  • Upgrade the OpenSSL version to 1.0.1g
  • Request revocation of the current SSL certificate
  • Regenerate your private key
  • Request and replace the SSL certificate

Examples of Heartbleed security attacks: information disclosure on Concrete5, port 1433, server returning more data

10. Unvalidated redirects and forwards

Unvalidated redirect vulnerabilities occur when an attacker is able to redirect a user to an untrusted site when the user visits a link located on a trusted website. This vulnerability is also often called Open Redirect.

It is possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials.

How to test unvalidated redirects and forwards?

Spider the site to see if it generates any redirects (HTTP response codes 300-307, typically 302). Look at the parameters supplied prior to the redirect to see if they appear to be a target URL or a piece of such a URL. If so, change the URL target and observe whether the site redirects to the new target.

Web application security testing: preventing unvalidated redirects

  1. Simply avoid using redirects and forwards.
  2. If at all you’re using redirects/forwards, do not allow the url as user input for the destination. In this case, you should have a method to validate the URL.
  3. If you  cannot avoid user input, ensure that the supplied value is valid, appropriate for the application, and is authorized for the user.
  4. Map any such destination input to a value, rather than the actual URL or portion of the URL. Ensure that server side code translates this value to the target URL.
  5. Sanitize input by creating a list of trusted URL’s (lists of hosts or a regex).
  6. Force all redirects to first go through a page notifying users that they are going off of your site, and have them click a link to confirm.

Consider these examples: open redirect, open redirect in bulk edit

So, this was all about prevailing risks and web application security testing measures to prevent your website from attackers. For further queries & doubts, feel free to write to hello@mantralabsglobal.com

About the author: Rijin Raj is a Senior Software Engineer-QA at Mantra Labs, Bangalore. He is a seasoned tester and backbone of the organization with non-compromising attention to details.

Related:

Cancel

Knowledge thats worth delivered in your inbox

Smart Manufacturing Dashboards: A Real-Time Guide for Data-Driven Ops

Smart Manufacturing starts with real-time visibility.

Manufacturing companies today generate data by the second through sensors, machines, ERP systems, and MES platforms. But without real-time insights, even the most advanced production lines are essentially flying blind.

Manufacturers are implementing real-time dashboards that serve as control towers for their daily operations, enabling them to shift from reactive to proactive decision-making. These tools are essential to the evolution of Smart Manufacturing, where connected systems, automation, and intelligent analytics come together to drive measurable impact.

Data is available, but what’s missing is timely action.

For many plant leaders and COOs, one challenge persists: operational data is dispersed throughout systems, delayed, or hidden in spreadsheets. And this delay turns into a liability.

Real-time dashboards help uncover critical answers:

  • What caused downtime during last night’s shift?
  • Was there a delay in maintenance response?
  • Did a specific inventory threshold trigger a quality issue?

By converting raw inputs into real-time manufacturing analytics, dashboards make operational intelligence accessible to operators, supervisors, and leadership alike, enabling teams to anticipate problems rather than react to them.

1. Why Static Reports Fall Short

  • Reports often arrive late—after downtime, delays, or defects have occurred.
  • Disconnected data across ERP, MES, and sensors limits cross-functional insights.
  • Static formats lack embedded logic for proactive decision support.

2. What Real-Time Dashboards Enable

Line performance and downtime trends
Track OEE in real time and identify underperforming lines.

Predictive maintenance alerts
Utilize historical and sensor data to identify potential part failures in advance.

Inventory heat maps & reorder thresholds
Anticipate stockouts or overstocks based on dynamic reorder points.

Quality metrics linked to operator actions
Isolate shifts or procedures correlated with spikes in defects or rework.

These insights allow production teams to drive day-to-day operations in line with Smart Manufacturing principles.

3. Dashboards That Drive Action

Role-based dashboards
Dashboards can be configured for machine operators, shift supervisors, and plant managers, each with a tailored view of KPIs.

Embedded alerts and nudges
Real-time prompts, like “Line 4 below efficiency threshold for 15+ minutes,” reduce response times and minimize disruptions.

Cross-functional drill-downs
Teams can identify root causes more quickly because users can move from plant-wide overviews to detailed machine-level data in seconds.

4. What Powers These Dashboards

Data lakehouse integration
Unified access to ERP, MES, IoT sensor, and QA systems—ensuring reliable and timely manufacturing analytics.

ETL pipelines
Real-time data ingestion from high-frequency sources with minimal latency.

Visualization tools
Custom builds using Power BI, or customized solutions designed for frontline usability and operational impact.

Smart Manufacturing in Action: Reducing Market Response Time from 48 Hours to 30 Minutes

Mantra Labs partnered with a North American die-casting manufacturer to unify its operational data into a real-time dashboard. Fragmented data, manual reporting, delayed pricing decisions, and inconsistent data quality hindered operational efficiency and strategic decision-making.

Tech Enablement:

  • Centralized Data Hub with real-time access to critical business insights.
  • Automated report generation with data ingestion and processing.
  • Accurate price modeling with real-time visibility into metal price trends, cost impacts, and customer-specific pricing scenarios. 
  • Proactive market analysis with intuitive Power BI dashboards and reports.

Business Outcomes:

  • Faster response to machine alerts
  • Quality incidents traced to specific operator workflows
  • 4X faster access to insights led to improved inventory optimization.

As this case shows, real-time dashboards are not just operational tools—they’re strategic enablers. 

(Learn More: Powering the Future of Metal Manufacturing with Data Engineering)

Key Takeaways: Smart Manufacturing Dashboards at a Glance

AspectWhat You Should Know
1. Why Static Reports Fall ShortDelayed insights after issues occur
Disconnected systems (ERP, MES, sensors)
No real-time alerts or embedded decision logic
2. What Real-Time Dashboards EnableTrack OEE and downtime in real-time
Predictive maintenance using sensor data
Dynamic inventory heat maps
Quality linked to operators
3. Dashboards That Drive ActionRole-based views (operator to CEO)
Embedded alerts like “Line 4 down for 15+ mins”
Drilldowns from plant-level to machine-level
4. What Powers These DashboardsUnified Data Lakehouse (ERP + IoT + MES)
Real-time ETL pipelines
Power BI or custom dashboards built for frontline usability

Conclusion

Smart Manufacturing dashboards aren’t just analytics tools—they’re productivity engines. Dashboards that deliver real-time insight empower frontline teams to make faster, better decisions—whether it’s adjusting production schedules, triggering preventive maintenance, or responding to inventory fluctuations.

Explore how Mantra Labs can help you unlock operations intelligence that’s actually usable.

Cancel

Knowledge thats worth delivered in your inbox

Loading More Posts ...
Go Top
ml floating chatbot