Application Security - PowerPoint PPT Presentation

Loading...

PPT – Application Security PowerPoint presentation | free to view - id: 271ce-YTI5M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Application Security

Description:

Proxies are employed in many situations such as offices and cyber cafes to share ... There are several browser proxies that are capable of not only examining data ... – PowerPoint PPT presentation

Number of Views:2819
Avg rating:3.0/5.0
Slides: 106
Provided by: ewhI
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Application Security


1
Application Security
  • Satish Babu
  • Chair, Computer Society
  • IEEE Kerala Section
  • President, InApp Information Technologies,
    Technopark

2
Rule 0 of Application Security The most
powerful weapon that an attacker has, is the
unsuspecting user...
3
Overview
  • Introduction
  • Network vs. Application security
  • Concepts in cryptography
  • Application-level vulnerabilities
  • Web vulnerabilities
  • Top 10 web vulnerabilities
  • Google hacking
  • Spam, Spim and Scams
  • Conclusion

4
Disclaimer
  • This presentation is meant to familiarize
    participants with several security holes that
    exist in commonly-used software so as to
    sensitize them to the need for security
  • In the process, it uses tools and techniques
    that, if applied in real-life, may attract
    prosecution
  • Any real-world examples used here are only used
    for illustrative purposes and does not imply that
    the particular site has less security than others
  • In particular, neither the speaker nor the
    organizers endorse any act such as forced entry
    into computers or the illicit retrieval and
    misuse of user credentials

5
Pre-requisites and desirables
  • Pre-requisites
  • A sound knowledge of the workings of networks,
    TCP/IP and application-level protocols
  • Exposure to a programming language
  • Good knowledge of HTML
  • Desirable
  • Substantial exposure to the web

6
Application and Network Security
  • Introduction

7
Security is not a device, but a process. It is
not the destination, but the journey
itself... Anonymous quote
8
Security
  • Security was not a concern for developers and
    systems programmers till the early 90s
  • However, after the coming of the Internet and the
    spread of distributed applications, security has
    become a major concern
  • Security concerns came into the limelight with
    threats as viruses, trojans, worms, and
    crackers, especially as valuable data went on
    the Network

9
Note Values for 2005 projected from first two
quarters
Source http//www.cert.org (CMU)
10
Application security
  • These days, security is a concern at two levels
  • Network security
  • Application security
  • The former is concerned about low-level security
    during processes such as transport, routing, and
    other TCP/IP protocol stack operations
  • Application security refers to security concerns
    at a higher levelthe level of applications

11
Network security
  • In the late '90s, the TCP/IP protocol stack was
    under threat, with various DoS/DDoS/ penetration
    attacks such as
  • SYN flood
  • UDP bombs
  • Finger bombs
  • Ping of death
  • Broadcast storms
  • Smurf/Fraggle attacks
  • Nestea, Jolt, Teardrop, Bonk...

12
Application security
  • However, the last decade has seen significant
    improvements in Network security
  • The crackers or black-hat hackers have
    therefore turned their attention to application
    security
  • Application security was not a concern for
    developers until about 2-3 years back
  • This presentation will focus on application
    security

13
Type of applications
  • For security purposes, applications can be
    classified as client-server or web-based
  • The former includes all programmes running on a
    host with no or local back-ends
  • These applications are usually written in a
    language such as C/C/Java/VB etc, and have
    different security implications as compared to
    web apps

14
Some common non-web exploits

15
Buffer overflow
  • Buffer overflow is a commonly-seen problem with
    programmes written in C, C or assembler
  • Java, C or VB are not usually affected by this
    problem
  • Many of the system utilities (eg., named,
    sendmail, ftpd) are written in C, and are hence
    vulnerable

16
Buffer overflow
  • Buffer overflow happens when data that is too
    large is copied into a buffer
  • When this happens, the extra bytes overwrite some
    part of the memory
  • What this does depends on the OS and the program,
    but in general, something bad happens

17
Trashing the stack
  • What the cracker does goes beyond merely crashing
    the programme
  • The cracker overwrites memory in such a way that
    the return address of a function (on the stack)
    is overwritten by the address of a function that
    s/he has written
  • Typically this short function spawns a shell.
    Such a shell will have full privileges of the
    original programme

18
printf exploits
  • The printf function prints formatted strings. It
    is usually difficult to crash printf, but there
    is one exception
  • The n format specifier of printf writes to a
    pointer (all other FSs read a variable and prints
    it). This FS writes the number of strings output
    so far
  • The function does not check the validity of the
    destination address

19
Printf exploit
  • // vulnerable
  • void main(int ac,
  • char av)
  • printf(av1)
  • // Immune
  • void main(int ac,
  • char av)
  • printf(s,av1)
  • This code prints out the first command line
    argument, but is vulnerable
  • a.out hello
  • hello
  • a.out nn
  • segmentation fault

20
Vulnerable APIs
  • The following have been identified as dangerous
    to use
  • strcpy,wcscpy,lstrcpy and mbscpy
  • strcat, wcscat, lstrcat
  • memcpy
  • sprintf, printf, scanf, sscanf
  • strlen
  • gets
  • The insertion operator of C

21
Cryptography for security
  • Some basic concepts

22
Cryptography
  • Cryptography has become a main element of data
    security today
  • Cryptography is defined as the science of
    obscuring and de-obscuring data for the purpose
    of rendering it inaccessible during storage and
    transmission
  • Cryptography depends on algorithms that are
    computationally expensive to break

23
Security issues
  • Confidentiality (message should not be read by
    others)
  • Authentication (confirming identity)
  • Integrity (message not altered in transit)

24
Storing passwords
  • On most situations, security starts with storing
    passwords, as most authentication techniques are
    password or passphrase-based
  • Storing passwords in plaintext is highly risky,
    as all passwords will be exposed if an attacker
    gains control to the system
  • In most modern operating systems, the password is
    not stored at all

25
Hashes
  • Hashes are one-way functions. Any string can be
    hashed to a fixed-length hash, but it is
    impossible to get the original string back from
    the hash
  • Well-known hashing algorithms are MD5, SHA1, both
    available in Javascript
  • Most OSes store only the hash of the password. It
    is computationally impossible to get the password
    from the hash.
  • Authentication is done through hashing the
    password entered by the user and comparing

26
Salted hash
  • Hashing is not secure against brute force or
    replay attacks. For additional safety, a random
    number (based on session, time etc) called the
    salt is used
  • Rehashing the salt is called salting a hash
  • Hash the first string
  • Append the salt to the hash
  • Hash it again
  • Salted hashes are much more secure, as each
    password may be hashed with a different salt,
    thus increasing the computational complexity

27
Encryption
  • Encryption refers to transforming data (plain
    text) through a series of arithmetical
    operations into a unreadable form (cipher text)
  • Encryption uses a key (usually a string) for
    added security
  • The cryptographic strength of the encryption
    depends on the algorithm and the key length

28
Symmetric key crypto
  • Both encryption and decryption are done using the
    same key in this case
  • Reasonably good security and performance
  • But several problems
  • transporting the key
  • Secure storage of too many keys (one per peer)
  • Prone to brute force attacks (a DES message was
    broken in 4 months by brute force). Can be made
    even more secure by sequential encryption (3DES)

29
(No Transcript)
30
Public key crypto
  • Public (or asymmetric) key crypto operates with
    two keysone public key and the other private key
  • Text that is encrypted with one key can only be
    decrypted with the other key
  • A person distributes his public key to all his
    friends (and enemies) who would like to
    communicate with him either directly, or through
    a certifying authority
  • He keeps his private key secure, and only known
    to himself

31
(No Transcript)
32
(No Transcript)
33
PK crypto
  • There is no need of a secure key exchange as in
    the case of symmetric key crypto
  • PK crypto is computationally heavier than
    symmetric key crypto, leading to performance
    problems
  • In many cases, a combination of the two is used,
    where the PK is used for secure transmission of
    the symmetric key

34
Digital signatures
  • If a message should be readable but not
    modifiable, a digital signature is used to
    authenticate the sender
  • Bob writes a message and computes its hash. The
    hash is encrypted with Bob's private key and the
    resulting signature is appended to the message
  • Alice confirms that it is Bob who sent the mail,
    by decrypting the signature with Bob's public
    key, recomputing the message hash and comparing
    the two

35
Digital Signatures
36
Digital certificate
  • While interacting with unknown parties over the
    web, this scheme is not sufficient. The identity
    of Bob (that it is really Bob and not someone
    else using his name) needs confirmation
  • This requires an additional document, a digital
    certificate
  • Certificates are usually issued by globally
    trusted agencies

37
Digital certificate
  • Consists of
  • Issuer's name (eg., Verisign, Thawte)
  • Validity duration
  • Subject's name and site address
  • Subject's public key encrypted with CA's private
    key

38
Digital certificates
  • When Alice gets Bob's message, she asks for his
    digital certificate and public key
  • She downloads the CA's public key, decrypts the
    certificate to obtain Bob's public key, and
    compares it with the key that she obtained from
    Bob
  • This is the basic schema used for SSL

39
SSL/TLS
  • SSL secures point-to-point traffic (though not
    necessarily end-to-end traffic)
  • SSL can use self-certification, in which case
    users cannot cross-check the server's identity
  • A Certifying Agency (CA) issues verifiable
    certificates
  • CA's require one or more dedicated IPs, domain
    names, and other information for issuing
    certificates
  • Certificates are issued for a valid period, and
    can be revoked

40
A simplified view of SSL
ALICE BOB
Hi, I'm Alice.Who are you?
I'm Bob. Here's my certificate
Prove it!
Alice, this is Bob digestAlice, this is
Bob Bob's PrivKey
If found ok, sends A symmetric keyBob's
PubKey
Decrypts using PrivKey, and starts transmission
using symmetric key
Continues to use the same symmetric key
41
Web exploits

42
The web
  • The web was not designed with security in mind
  • The typical web user is not very educated, nor
    security conscious
  • In fact, even some System Administrators are not
    sufficiently security conscious!
  • The wide distribution of access points (eg.,
    cyber cafes) also makes building secure
    applications a challenge
  • A large number of applications use the web
    (informational, educational, entertainment,
    transactional, governance...) as transport

43
Common web security myths
  • The user will always submit the appropriate
    kind of data
  • Javascript will take care of validation
  • Our site runs on SSL with 128-bit encryptionso
    we are absolutely safe
  • Server side validation is a waste, as we are
    already doing client-side validation

44
Browser proxy tools
  • Proxies are employed in many situations such as
    offices and cyber cafes to share an Internet
    connection among many machines
  • There are several browser proxies that are
    capable of not only examining data that passes
    through them, but also modifying the data. These
    are a tool for hackers
  • Examples are Achilles (Windows) and Paros
    (multiplatform)

45
Common web exploits
  • URL manipulation
  • Password guessing
  • Proxies and man-in-the-middle attack
  • HTML comments
  • Forgot password implementations
  • Keystroke loggers
  • SQL injection
  • Command injection
  • XSS

46
HTTP Basics
  • HTTP is based on a series of request-response
    cycles
  • Requests are originated by the client, while the
    server sends out the requested resource (provided
    it exists, and user is authorised)
  • HTTP is a stateless protocolthe server closes
    the connection immediately after sending out the
    required resource
  • Built-in security features of HTTP is very
    minimal and insufficient

47
GET and POST
  • Requests are made by the client using either GET
    or POST header methods (there are three more
    methods which are for specialized use)
  • In both, the browser sends across a resource
    name, together with optional additional data
    (eg., form data) to the server
  • GET is simpler and has size limitations. In
    theory, GET is to ask for information, while POST
    is to contribute information. Programmatically,
    they are almost identical in the new frameworks
    like PHP, ASP or JSP

48
HTML clues
  • Programmers may leave clues in the code about
    user names
  • In some cases, the passwords can be guessed,
    especially if the hacker knows the victim
    reasonably well

49
Hidden field manipulation
  • Hidden fields can easily be seen and modified
    from within a proxy
  • Therefore, storing important information (eg.,
    userid, password, PIN) in hidden values is a very
    bad idea

50
Spoofed links in emails
  • It is easy to spoof email links in HTML-based
    emails (also used in phishing)
  • An innocent-looking link may actually be going
    somewhere dangerous
  • There have been cases where entire sites have
    been dynamically displayed through a back-to-back
    connection

51
JavaScript validation
  • Some programmers repose too much faith in
    client-side validation such as that using
    JavaScript
  • However, such validation becomes totally useless
    in the face of proxies that modify parameters on
    the fly

52
Unprotected admin scripts
  • Many sites have admin interfaces for changing
    settings
  • All admin interfaces are usually protected using
    password or SSL
  • However, sometimes some of the other admin
    components are accessible even without a valid
    login, as the adminstrators think that since no
    link exists, people can't make out that such
    pages exist

53
Weak access control
  • If web directories are not given proper access
    privileges, an ordinary form can become
    vulnerable
  • This can be used to get contents of sensitive
    files

54
Forgot password scripts
  • Many sites have a Forgot password feature that
    often becomes a security flaw
  • These scripts are not sufficiently tested as they
    are of low priority
  • These days, Forgot password scripts are
    implemented through security questions that make
    it harder to break

55
Weak cookies
  • Session handling is done usually through cookies
  • However, many server-side programmes created
    cookies in a simplistic manner
  • These cookies can be reverse-engineered to hijack
    sessions
  • Ideally, session validation should be based on
    cookies IP or some other parameter

56
XSS
  • Cross-site scripting is a complex process
  • Attacker logs in into an on-line forum
  • He makes an entry here that will be read by
    anyone who wants to read it
  • Embedded in his routine text entry is a
    ... section which contains
    malicious code.
  • He logs out
  • The site is visited by some unsuspecting victim
    who clicks the attacker's entry
  • The victim's browser executes the malicious code,
    which sends sensitive information to the attacker

57
XSS vulnerable targets
  • Targets are
  • Bulletin boards
  • Blogs
  • Chatrooms
  • Guest books
  • Anything else that reflects browser inputs
    without validation
  • Sanitize data (ie., remove HTML, and
    several other characters in postings)

58
Command injection
  • Weakly coded applications are vulnerable to
    injection of commands into a form
  • Since can Unix take multiple commands in a single
    line, all the user has to do is to enter his
    command after a semicolon (which is a command
    separator)

59
SQL injection
  • A serious flaw with dynamically-built SQL queries
  • Can result in significant loss of confidentiality
    or even loss of entire database
  • Always use PreparedStatement or CallableStatement
    in Java or ADO in .NET
  • Validate and Sanitize data before using

60
URL manipulation
  • When GET is used for form submission, all the
    fields are exposed in the URL line in the browser
  • This makes it easy to change things on the
    submitted query
  • Can be avoided by using POST instead of GET
  • If GET is required for some reason, then
    cryptographic protection of parameters is required

61
Fail-open authentication
  • Hackers armed with proxies can provide unexpected
    inputs to the application (so never trust
    client-side validation alone)
  • Some applications are coded in such a way that
    when they fail, they leave the door wide open...!
  • This can be a potent tool for the hacker

62
Browser refresh
  • Browsers cache entire submissions in their memory
  • Even after logout (and session invalidation),
    these can be retrieved by the back key followed
    by a refresh if the browser is not closed

63
Phishing
  • A high-tech scam of spoofing trusted sites by
    misleading links (esp. in HTML mail or a link
    like www.ebay.com_at_members.tripod.com)
  • Aimed to fool inexperienced (and some
    experienced) users
  • Can result in loss of user credentials and
    financial loss

64
(No Transcript)
65
(No Transcript)
66
(No Transcript)
67
(No Transcript)
68
Name similarities
  • www.mcrosoft.com
  • www.whithouse.org, www.whitehouse.com
  • www.ebay.com_at_members.tripod.com
  • www.nasa.com
  • WWW.VERlSIGN.com
  • www.paypa1.com
  • https//www.paypal.comacalksdjff_at_KI54fT.WoRlDiSp
    NeTwOrK. CoM/i.CgI? billing_at_yourdomain.com
  • 99107101114.comHello

69
Evading phishing
  • User awareness (look carefully twice)
  • Never click on an email link to go to a financial
    site
  • Never respond to financial mail
    immediatelyalways cross check off-line
  • Look at the status bar to see whether a link
    points to the real site

70
Keystroke loggers
  • Keystroke loggers can be hardware or software
  • Software loggers are trojans that log all
    keystrokes into a file (or email it out to the
    perpetrator daily)
  • Hardware loggers can be impossible to detect
  • These can defeat most of the methods that we
    discussed so far
  • More sophisticated techniques are required to
    beat these graphical entry of login (with the
    mouse),

71
Passwords in memory
  • Passwords remain in the memory of the computer
    that runs it (even when it can't be displayed in
    the password field)
  • If a running programme can be examined by a
    memory scanner, the password can be destroyed
  • Even after the programme exits, the password can
    be discovered unless it is explicitly cleared
    programmatically (cat /dev/mem /tmp/mem)

72
Proxies and SSL
  • Web proxies can defeat SSL by the classic
    man-in-the-middle strategy
  • When the client asks for a https site, the proxy
    in turn contacts the site and gets its
    certificate
  • It then gives a validbut self-issuedcertificate
    to the client. Most clients will now pop up a box
    saying the certificate is untrusted (and most
    uneducated users will continue browsing)
  • From then on, there are two back-to-back secure
    connections client-proxy and proxy-server

73
Pharming
  • Pharming exploits vulnerabilities on DNS servers
    and their caches
  • The strategy is to hijack a website's DNS entry,
    thereby redirecting the site to a bogus page,
    even when the user types in the correct name
  • Many sites such as ebay.de, hushmail.com and
    panix.com were hijacked like this

74
Evil Twin
  • An evil twin is a spoofed wireless hotspot that
    pretends to be legitimate
  • This has happened in restaurants, public places
    and even conferences
  • In April 2005, fraudsters set up an Evil Twin in
    a conference in London, pretending to be the
    official Wi-Fi providers
  • When users connected, not only were their
    passwords stolen, but they were also infected
    with an array of about 45 viruses

75
OWASP Top ten most critical vulnerabilities

76
1. Unvalidated input
  • Attackers can tamper with any part of the input,
    including the URL, querystring, headers, cookies,
    form fields and hidden fields
  • Resulting vulnerabilities include buffer
    overflow, format string, forced browsing (ie.,
    deep link browsing), injection etc
  • Server-side validation is absolutely essential

77
2. Broken access control
  • Insecure access control IDs (Eg., admin, manager,
    editor)
  • Forced browsing past by-passable deep links
  • Path traversal (..\..\target_dir\secret_file)
  • Inappropriate file permissions
  • Browser caching from insecure locations
    (libraries, cyber cafes)

78
3. Poor session management
  • Poor password strength
  • No locking after fixed number of wrong logins
  • Insecure password change mechanisms
  • Plaintext password storage
  • Insecure transmission of credentials
  • Insecure transmission of session ID
  • Passing of credentials in GET

79
4. XSS (Cross-site scripting)
  • Can be stored or reflected
  • Malicious portions often encoded (including using
    Unicode)
  • Any embedded content including ActiveX, VBScript,
    Flash or Shockwave can be malicious
  • HTML user input must be sanitized in order to
    prevent this

80
5. Buffer overflows
  • Due to inappropriate use of certain C/C
    functions that attack the stack
  • Can be detected by a security code review
  • Earlier several Internet applications were
    vulnerable (eg., sendmail, named), but now these
    have been fixed

81
6. Injection flaws
  • Injection of commands or SQL into forms
  • Command injection generally a problem of Perl,
    python and other interpreted languages
  • SQL injection is a consequence of näive SQL code
    (dynamic code as opposed to prepared statements)
  • Always validate and sanitize user data

82
7. Improper error handling
  • Error messages sometimes reveal too much
    information about the platform, server, and
    application
  • This can provide clues to enterprising attackers

83
8. Insecure storage
  • Storage of sensitive information (credit card
    numbers, PIN numbers) on insecure storages
  • Failure to encrypt critical data
  • Insecure storage of keys, certificates, passwords
  • Poor sources of random numbers
  • Poor choice of algorithms
  • Attempting to invent own encrypting system
  • Failure to include support for encryption key
    changes and other maintenance

84
9. Denial of service
  • Difficult to distinguish between attacks and
    genuine requests
  • Therefore, difficult to protect against such
    attack
  • Fixing process/user quotas for CPU time and
    memory may help

85
10. Insecure configuration mgmt
  • Configuration/Deployment management may also have
    problems
  • Unpatched flaws in server-side software
  • Misconfiguration allows directory listings and
    directory traversal attacks
  • Unnecessary files (default, backup, samples..)
  • Unnecessary services enabled
  • Default out-of-the-box accounts passwords
  • Admin/debug functions enabled

86
Why look for back-doors when you can waltz in
through the front door?
Welcome to Google hacking!

87
Google hacking
  • As many first-time programmers and administrators
    took to the Internet, most using tools that are
    meant for novices, security lapses have become
    quite common
  • Google, through its powerful API, can be used to
    quickly pinpoint such vulnerabilities
  • Since Google indexes sites without even the
    administrator noticing, many sites have found
    their sensitive documents available in public

88
Google search operators
  • The site operator can be used to list down all
    pages in a given site
  • eg., sitehttp//www.microsoft.com XP will
    locate all pages at Microsoft that contains the
    word XP
  • The inurl operator locates a word in the URL
    string
  • eg., inurlindex.of parent directory gives
    several sites that have inadvertently exposed
    whole directories

89
Google operators
  • The same command can be used to locate servers
    with a particular version number (quite handy for
    locating vulnerable releases)
  • The query allintitleWelcome to Internet
    Information Server would fetch the list of all
    out-of-the-box installations of IIS
  • The filetype operator can show selected file
    types (eg inurledu inurlgrades filetypexls

90
Weak CGI spotting
  • There are several weak CGI vulnerabilities that
    can be spotted using Google
  • /cgi-bin/web2mail.cgi (mail out /etc/passwd)
  • /random_banner/index.cgi?image_list
    alternative_image.listhtml_file../../../../../et
    c/passwd (display passwd as a banner)

91
File spotting
  • Some files may contain interesting information
  • Personal history and details
  • Medical history
  • Organizational records
  • Financial information
  • Google has recently added number spanning
    searches (eg., 15-20), and hackers have already
    used it for searching for credit card numbers
    (visa 4356000000000000-4356999999999999)

92
Spam, Spim, Scamsand cyber terrorism

93
There's a popular saying that the only secure
computer is one that's turned off. Clever, but
false The pretexter simply talks someone into
going into the office and turning that computer
on... Kevin Mitnick, Cracker turned security
consultant
94
Social Engineering
  • The weakest link in the security chain is often
    the unprepared user/staff member, who gives out
    seemingly-inoccuous pieces of information
  • In most corporate attacks, the attacker uses the
    tools of social engineering, together with good
    planning, an intimate knowledge of the
    environment/technology and audacity
  • Kevin Mitnick, the legendary phreaker-cracker has
    outlined the power of social engineering in his
    masterpiece, The Art of Deception

95
Spam
  • Spam has become a major consumer of bandwidth,
    disk space and users' time, with imputed costs
    running into millions of dollars
  • All kinds of material ride the Net as spam chain
    letters, advertisements, virus hoaxes, scams...
  • Never reply to spam, as the spammer now knows
    that he has a valid email ID
  • Despite legislation, spam filters and smart mail
    clients (eg., gmail), spam occupies about 30 of
    all email today, growing at about 20 each year

96
Spam and Spim
  • At this rate, 99 of all email will be spam by
    the year 2009 !
  • Some spammers user automated techniques (eg., a
    graphic image embedded in a spam through a CGI
    script) to separate real email ids from fake ones
  • Spim is similar to spam, but the carriers are IMs
    (Instant Messengers)
  • Spim is set to treble from 400 million in 2003 to
    1.2 billion this year

97
Scams
  • There are several scams that are using the
    Internet and print media to circulate
  • Nigeria (419) scam
  • Auction fraud
  • Patent medication (Cialis, herbal viagra)
  • Pump-and-dump stock market scam
  • Viruses
  • Chain letters (Microsoft will pay you 25)
  • Identity theft
  • Lottery

98
Scams
  • Work from home and make big money
  • Health and diet scams
  • Spy on anyone
  • Get credit card numbers and site passwords
  • Scholarship scams
  • Telephone billing scam (bills are charged to
    telephone accountsthe lost pet scam)
  • Get a college degree
  • Get software cheap
  • 9/11 donations
  • Free computers (cameras, printers...)

99
Auction scams
  • Misrepresentation of item or value
  • Failure to ship
  • Failure to pay (bounced cheques, stolen cards)
  • Shilling (artificially boosting bids by
    accomplices)
  • Bid shielding (using phony bids to scare away
    real bidders and finally retracting the bid)
  • Piracy (of music or other counterfeit material)
  • Fencing (selling stolen goods)
  • Buy and switch (buying and then returning a
    different, but damaged item)
  • Shell auction (no merchandise exists)

100
Identity theft
  • When someone appropriates your personal
    information in order to commit fraud or theft
  • Credentials (Name, email, address, social
    security number, credit card number) can be
    obtained through a variety of mechanisms
    (including a lost wallet)
  • In the West, ID theft can be serious, as the
    fraudster can completely take over the ID (and
    deny the original owner of medical care, bank
    credit and even mail!)

101
Cyberterrorism
  • After 9/11, there is substantial attention on the
    use of the Internet by terrorist groups
  • These groups use techniques such as steganography
    to multicast messages
  • Apart from images and sounds, the latest
    discovery is that secret messages can be hidden
    in in the most common mail--Spam!

102
Conclusions

103
Conclusions
  • There are a large number of motivated and
    malicious people who attack sites, be it for
    profit or the thrill
  • Until we use better tools, techniques and
    discipline, there is the risk of our sites being
    defaced, used as the base of attacking other
    sites, or worse, losing valuable information
  • The age of innocent coding is over, and it is
    time that every site on the Internet paid
    attention to application security

104
References
  • Innocent Code A Security Wake-up Call for Web
    Programmers by Sverre H. Huseby
  • CERT, http//www.cert.org/
  • OWASP, http//www.owasp.org
  • Johnny Long, http//www.ihackstuff.com
  • The Art of Deception by Kevin Mitnick
  • Wikipedia (http//www.wikipedia.org) pages on
    security
  • The Ten Immutable Laws of Security at
    http//www.microsoft.com

105
Thank you.
About PowerShow.com