DZone
Security Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Security Zone > Framework Security: Building Self-Protecting Applications

Framework Security: Building Self-Protecting Applications

What if you could give the security technology access to the actual execution state of the app? Some sort of infallible system to automate what is really a simple, repetitive task to enable the frameworks to defend themselves?

Oliver Lavery user avatar by
Oliver Lavery
·
Dec. 01, 16 · Security Zone · Opinion
Like (3)
Save
Tweet
2.11K Views

Join the DZone community and get the full member experience.

Join For Free

The Problem with Web Security

Humans are, alas, highly fallible beings. While we are good at creativity and reason, we are pretty bad at mechanically applying rules and taking care of repetitive tasks. And what is web application security, really, but the ability to consistently, accurately, and repetitively apply the right rules to protect against vulnerabilities and threats?

If HTML wasn’t such a mess, maybe all of this would be easy. What about WAFs, you ask? Web application firewalls are a good first step. But they don’t cut it; they can’t take you all the way. Because they don’t have access to what is going on inside the app, they can only look at inputs and outputs to a black box.

What if, instead, you could give the security technology access to the actual execution state of the app? You know, some sort of infallible (i.e., non-human) system to automate what is really a simple, repetitive task to enable the frameworks to defend themselves?

Solution: Framework Self Defense

Real web applications are messy. Sometimes that is because of a design error, sometimes a coding error, sometimes none of the above. Building a strong framework is the only way to:

  • Access the internal state to gain more information and enable smarter decisions
  • Intelligently modify app behavior
  • Avoid having to update code
  • Protection across a portfolio of applications

There are some real benefits of securing the framework, thus reducing the impact from coding or development mistakes. From inside the app using agent based runtime application self-protection (RASP) technology you can centrally report events, detect attacks, and prevent against the major vulnerabilities such as cross-site scripting (XSS) and SQL injection.

XSS Example

Preventing XSS illustrates the power of this approach. The conventional wisdom to prevent XSS (and the approach used by many frameworks like Rails) is to escape the greater-than (>) and less-than (<) characters to prevent users from including tags in their input.

This approach doesn’t work in many cases. The challenge of XSS is that the correct escaping depends on the context that user supplied data is put into HTML.

Consider this common example:

<a href=”user-input”>link</a>

Preventing the user-input from containing < and > in this case achieves very little. There are a number of strings that would be executed as script in this context:

  • javascript:alert(0)
  • &#x6a;&#x61;&#x76;&#x61;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;&#x3a;&#x61;&#x6c;&#x65;&#x72;&#x74;&#x28;&#x31;&#x29;
  • “ onClick=”alert(1)
  • etc.

None of these malicious payloads include < or > and only one of them includes a quotation mark. Yet including user input in URLs is extremely common. The OWASP XSS Prevention Cheat Sheet lists 7 rules and roughly 8 different contexts that developers must faultlessly apply when building web applications or they risk introducing XSS vulnerabilities. It’s no wonder XSS is so common in real world applications!

This is a perfect example of a problem that’s poorly suited to human developers, but easy for machines to solve. Since RASP products are part and parcel of the applications they protect, it is simple for them to parse the HTML templates being rendered, understand where user supplied data might be placed into the page, and perform the correct contextual output escaping on the fly!

In the case of IMMUNIO, the first two payloads above will simply be removed since they are javascript: URLs. The third will be escaped to ensure browsers treat it as part of the URL itself, rather than introducing a new onClick attribute.

Protecting Software With Software

Good software design is critical. Yet, no matter how fabulous your development team, people will make mistakes and hackers will find ways to exploit them. The best solution is to have technology like RASP build a strong foundation and provide a safety net for your apps.

Web application Framework security

Published at DZone with permission of Oliver Lavery, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Demystifying Cloud-Native Data Management: Layers of Operation
  • Handling Multiple Browser Windows and Tabs in Selenium PHP
  • RestTemplate vs. WebClient
  • Secure Your WSO2 Micro Integrator Deployment

Comments

Security Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo