Embed Size (px)
Citation preview
“Embiggen your app"
Serge Borso – JAN 2015
Empowering your web application to defend itself
Intro: Who am I? Background: Jurassic park (1993)
SANS Mentor Penetration testing – vulnerability research
Talking Points
Current architecture – the way it is today Example Scenario Addressing the gap The “code” Demo time Risk Management
Keep it breezy
Let’s have fun! Ask questions Looking for interactivity, not a lecture
There are lots of things I don’t know…Just throwing that out there
Today’s world
Typical setup
ISP – Internet connection Router Firewall ↓ IPS/IDS maybe a WAF ↑ Load balancer Web farm Your application
What happens when the application is targeted*?
Will your ISP block malicious requests? Will the firewall block that? What about your IPS or WAF? How about the application?
*The target of an attack like SQLi, harvesting, spambots, XSS, etc…
“Security is everyone's responsibility”
Lots of products exist to stop X But what, if any, security is the
application responsible for?
Problem is… When it’s everyone's responsibility, it
quickly becomes no ones responsibility
To that end:
Separation of duties so to speak Utilize the best tool for the job
Seems logical right?Hard to do with all-in-one solutions
A WAF does fill a need, however…We don’t all have a WAFNot a panaceaBad practice to address an application
vulnerability with upstream device
What's the purpose of this then? I’m an advocate for application security Let the application defends itself Caveats
Has to look good, no really (transparent) Has to work wellHas to be convenientHas to be secureNeeds to be an appropriate solution for the
given problemAnd maintainable
Example scenario:Enter the iCloud celebrity hack
Apple was NOT breached There was a bug though So what happened?
How are accounts compromised? Myriad ways, but essentially two groups
Because of you and things in your control○ Password = Qwerty1!○ Infected machine/ already pwned
Because of the app and things outside of your control○ App allows for unlimited guessing○ Poor corporate/security practices
Apple didn’t stop it…
And that’s a $billion companyWhat chance then do we have to secure our
app?
Let’s learn from their mistakes
A very good chance
Everybody’s got a thing webapp How we handle security varies Lots of homegrown solutions
What to do then?
Inconvenience users with a captcha? Profile the user, or at least the behavior Back in my online banking days that’s
what we did… Deviations from norm hit threshold, then
take this action
But what action?
In band or out of band I.E. an alert goes out and someone
looks at it Let’s have the application take action If deviation is > x then …
The premise
Lots of information to work with when trying to identify malicious behavior
Anonymous (no authentication required) website leaves less options
Essentially build a profile
What to look for… some ideas
Time35 requests in one second?Time to submit form less than 5 seconds?
Agent, referer (typo) Cookies enabled, js enabled Previous status codes: 403, 401, 503 Post vs Get, Post without previous GET Use whitelist and blacklist approach
Introducing the code It’s a “scoring” model Nefarious activity = higher score Higher score = tighter security
Disable functionality○ No wire transfers○ No PII visibility○ No account editing○ Kick user out/ block
Throw a CAPTCHA if you think it’s a bot The APPLICATION makes the decision
Progressively more challenging
If score > x then.. Force a page refresh and then:
Check if cookie was setCheck if js is enabled
Lots of criteria can be checkedNeed to know your application And your users
If it’s not a human you have options
Disable functionality Feel free to use a CAPTCHA at this point Throttle connection Honeypot!
Learn if you are being targetedOr just “a” target (not “the” target)
Block at the IPS layer
So what's happening? HTTP requests are being scrutinized We’re trying to determine what’s behind
the requestsA valid userA malicious userA robot
Then an action is taken May be prudent to communicate with
upstream device
Backup for a minute
Major problem with this whole concept It’s mostly all client-side variables Client-side means I can spoof it This is called…
Security through obscurity
Poor practice Once a bad actor knows the secret… The protection mechanism becomes
useless Easily bypassed
Live example
Going to use tamper data and a browser Make some requests See how the application responds
Actions
Write to Apache or IIS log then parse Integrate with fail2ban Integrate with OSSEC Integrate with IPS
Implications…
The benefit of this is boundary protection at the IPS layer
I.E. If the IP is bad and attacking this one app, then we should leverage this knowledge and block it from touching anything on our network
Managing the risk What is the criticality and sensitivity of
what you are trying to protect? (assess the risk)
User accounts connected to PCI? Or an email contact form? Often requires commensurate security
Opposed to a general solution I.E. the WAF will work for the contact
form, the PCI environment needs a closer look
Cromulent Questions?
