Dynamic Security Token Filtering for Web Application Firewalls

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current Web application security filtering methods fail to effectively prevent malicious user input data from reaching Web application servers, as they rely on static security information, require frequent updates, and are vulnerable to active hacking attempts, especially when encrypted communications are involved.

Innovation Solution

A security service is implemented on a Web application firewall or reverse proxy server to dynamically create and verify security tokens embedded in content description languages, ensuring that user input data conforms to predefined constraints by enriching the content description language with security tokens that are encrypted and digitally signed, thus preventing mismatched or inconsistent checks.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of manufacture

If static security information is used for filtering, then the security configuration is simple to set up, but the security checks become inconsistent and vulnerable to hacking attempts

Engineering Contradiction:
Improveease of setupVSAvoidsecurity check consistency
Core Design Contradiction:
Ease of manufactureVSReliability

Solution Approach 1:

The patent implements dynamic security tokens that are automatically generated and updated for each user interaction, replacing static security information. These tokens contain time-sensitive validation rules and are regenerated based on current system state, ensuring consistent security checks without requiring manual administrator updates.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system automatically generates, distributes, and validates security tokens without requiring administrator intervention for each update. The security service autonomously manages token creation, embedding validation logic directly into the web application forms, enabling self-updating security configurations.

Inventive Principle:
Principle #25Self-service

2Reliability

If security information is frequently updated, then the security checks remain consistent, but the maintenance burden increases

Engineering Contradiction:
Improvesecurity check consistencyVSAvoidmaintenance time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The security service automatically generates and updates security tokens without requiring administrator maintenance. Tokens are created on-demand for each user session and contain all necessary validation logic, eliminating the need for manual security information updates while maintaining consistent security checks.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

Security validation rules are pre-embedded within each security token during its generation. This preliminary embedding of validation logic ensures that consistent security checks are performed without requiring subsequent updates or maintenance, as each token is self-contained with its validation criteria.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If reverse proxy servers parse content description language for security, then security filtering is enabled, but the system complexity and update requirements increase

Engineering Contradiction:
Improvesecurity filtering capabilityVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent extracts security validation logic from complex server-side parsing mechanisms and embeds it directly into client-side web forms through security tokens. This extraction simplifies the server infrastructure by removing the need for complex content description language parsing, while maintaining security filtering capability through token-based validation.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

Security tokens act as intermediaries between the user interface and the security validation system. Instead of requiring complex parsing of content description language, the tokens provide a simplified structured format that enables security filtering through straightforward validation processes, reducing overall system complexity.

Inventive Principle:
Principle #24Intermediary (Mediator)

4Reliability

If encrypted communications are used, then data security is improved, but the ability to inspect and filter requests is reduced

Engineering Contradiction:
Improvedata securityVSAvoidrequest inspection capability
Core Design Contradiction:
ReliabilityVSDifficulty of detecting and measuring

Solution Approach 1:

Security validation rules and constraints are embedded into security tokens before encryption occurs. The tokens contain all necessary validation logic in an encrypted but structurally identifiable format, allowing the security service to inspect and validate requests without decrypting the entire communication stream, thus maintaining both encryption and inspection capability.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentEP2144420B1Web application security filtering
Publication Date: 2011.06.22 BARRACUDA NETWORKS AG
  • EP2144420B1 patent drawingFigure 1
  • EP2144420B1 patent drawingFigure 2
  • EP2144420B1 patent drawingFigure 3

AI summary

User inputs and/or URL requests in a content description language (for example HTML) are passing by a security service for example a Web application firewall or a reverse Web proxy server that is placed in front of Web application servers in order to protect the servers from hacking attempts. For validating Web form user inputs and/or URL requests and parameters the content description language is enriched by the security service with additional security tokens that are dynamically created based on the content being transferred. The user receives the information and sends back input and the security tokens. The security service, which added the security tokens, can then verify all provided user input data against the constraints described in the corresponding security token. As a result, the method may block the HTTP request or create log messages or notification events to react on violations of the user input data compared to the constraints in the security token.