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 > The Struts Saga Continues: Groundhog Day All Over Again

The Struts Saga Continues: Groundhog Day All Over Again

If you work in Security, you've already heard of the Struts CVE, and already fixed it. But now, there is yet another vulnerability. Read on for more.

Zaid Al Hamami user avatar by
Zaid Al Hamami
·
Mar. 30, 17 · Security Zone · Opinion
Like (1)
Save
Tweet
2.45K Views

Join the DZone community and get the full member experience.

Join For Free

In a previous blog post, I talked about the Struts CVE (CVE-2017-5638) that’s affecting much of the Java Web App world these days. A security engineer at IMMUNIO provided his technical perspective as well.

My argument was that we see this type of event all the time. Code is written, and vulnerabilities exist in it undetected for years. Then we have to rush to fix it immediately. Meanwhile, we have no idea if any damage has occurred. As is quite common in the security vendor world, vendors rush to tell you that they’ve provided a new ‘rule’ to prevent the exploitation. Unfortunately, as is the case with any blacklisting or pattern matching based technology, very rarely do you get it right the first, second, or third time.

Within a day or two, bypasses were disclosed to various vendors, some added new rules for those bypasses, some still haven’t. We actually figured out some more since then.

Well, now there’s another way to exploit the same vulnerability, that is not detectable by any rule or any WAF (to the best of our knowledge).

This time, however, it won’t be so easy for WAF’s to effectively secure against these exploits. The technical reason lies in the fact that the malicious payloads will reside in the body part of large multipart requests. If you have enough sites behind a WAF, enabling inspection on these will result in quite a bit of strain on the WAF (which translates to fail open or delay, depending on the vendor). Furthermore, there will be False Positives.

This is yet another example of why WAF’s are not effective Application layer protection technologies. Next-generation approaches, such as security instrumentation, and RASP, in particular, are much more adept at handling these types of issues. There is no pattern matching involved. It does deal with the variant cases as well. Our approach profiles your application. It understands its execution. It knows what commands should and should be allowed to execute. And it can show you all of that.

security application Vulnerability app Execution (computing) Adept (C++ library) Profile (engineering) Requests

Published at DZone with permission of Zaid Al Hamami. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Understanding OAuth 2.0
  • Is DataOps the Future of the Modern Data Stack?
  • No Code Expectations vs Reality
  • 3 Best Tools to Implement Kubernetes Observability

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