• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
So Your Company Hired A Pentester
 

So Your Company Hired A Pentester

on

  • 266 views

 

Statistics

Views

Total Views
266
Views on SlideShare
266
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    So Your Company Hired A Pentester So Your Company Hired A Pentester Presentation Transcript

    •  The contents of this talk are my own personal research and training. FishNet Security has no affiliation with this talk and can not be held responsible for any of its contents. As such it should not be seen as marketing or any other from of public interaction by FishNet Security.
    • No Really! Don‟t Panic!
    • Facebook WordPress
    • • The Internet is BIG• No, no no The Internet is REALLY REALLY BIG• To go along with this really big internet we have a really big Codebase• To add to this really big codebase, just like we learned in our first programming class there are a thousand ways to do just about anything .• Risk Assessment is more about hardening your web app or site to common attacks than uncommon attacks that target your unique situation.• Now you must be thinking whats a low hanging fruit?
    • • OWASP top Ten• OWASP is the open Web Application Security Project.• Every few years they put out a report of the top ten vulnerabilities found on the internet.• They Also have some great tools for testing your Web Applications.• If you want an Idea of how to prepare for a Security Audit OWASP is a great resource.
    • Injection means…• Tricking an application into including unintended commands in the data sent to an interpreterSQL injection is still quite common• Many applications still susceptible (really don‟t know why)• Even though it‟s usually very simple to avoidTypical Impact• Usually severe. Entire database can usually be read or modified• May also allow full database schema, or account access, or even OS level access
    •  Recommendations 1. Avoid the interpreter entirely, or 2. Use an interface that supports bind variables (e.g., prepared statements, or stored procedures),  Bind variables allow the interpreter to distinguish between code and data 3. Encode all user input before passing it to the interpreter  Always perform „white list‟ input validation on all user supplied input  Always minimize database privileges to reduce the impact of a flaw
    • Occurs any time…• Raw data from attacker is sent to an innocent user‟s browserTypical Impact• Steal user‟s session, steal sensitive data, rewrite web page, redirect user to phishing or malware site• Most Severe: Install XSS proxy which allows attacker to observe and direct all user‟s behavior on vulnerable site and force user to other sites
    •  Recommendations  Eliminate Flaw  Don‟t include user supplied input in the output page  Defend Against the Flaw  Primary Recommendation: Output encode all user supplied input  Perform „white list‟ input validation on all user input to be included in page  For large chunks of user supplied HTML, use HTML sanitization to sanitize all HTML and make it safe
    • Web applications rely on a secure foundation•Everywhere from the OS up through the App Server•Don‟t forget all the libraries you are using!!Is your source code a secret?•Think of all the places your source code goes•Security should not require secret source codeCM must extend to all parts of the application•All credentials should change in productionTypical Impact•Install backdoor through missing OS or server patch•XSS flaw exploits due to missing application framework patches•Unauthorized access to default accounts, application functionality or data, or unused but accessible functionality due to poor server configuration
    •  Verify your system‟s configuration management  Secure configuration “hardening” guideline  Automation is REALLY USEFUL here  Must cover entire platform and application  Keep up with patches for ALL components  This includes software libraries, not just OS and Server applications  Analyze security effects of changes Can you “dump” the application configuration  Build reporting into your process  If you can‟t verify it, it isn‟t secure Verify the implementation  Scanning finds generic configuration and missing patch problems
    • PKI VPNSSH/SFTP SSL
    • Does•Third Party Authentication•PKI encryption•Keeps the conversation between the client and the hostDoes Not•Protect the client from malware snooping or interference•Remove malicious code.Why Its not standard•Encryption is process heavy•The internet is oldWhen you should use it.•Always…•When dynamic code is used•At least when logins are in use anywhere on the site.
    • Does•PKI encryption•Keeps the conversation between the client and the hostDoes Not•Protect the client from malware snooping or interference•Remove malicious code.Why Its not standard•Encryption is process heavy•The internet is oldWhen you should use it.•Always…•When dynamic code is used•At least when logins are in use anywhere on the site.
    • Does•PKI encryption•Connects to your server for quick secure file management•Allows you to issue commands to your serverDoes Not•Help the Client•Provide any code sanitizationWhat It Replaces•FTP•God forbid TelnetWhen You Should Use It.•Anytime you connect to your server•All File transfer for source code•Editing any source on host
    • Email: carlton.sue@fishnetsecurity.comTwitter: @iamcoboltWeb: http://www.fishnetsecurity.com/BlogsPersonal: http://www.carlsue.com • https://www.owasp.org • Web Application Hackers Handbook • The Tangled Web – No Starch Press • SQL Injection Attacks and DefenseThanks For Having Me!