Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Building security into an agile internet banking project

No description
by

Anton Keks

on 26 September 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Building security into an agile internet banking project

Building
Anton Keks, @antonkeks
security
into an agile
internet banking
project
Agile
Security
Usability
vs
vs
Play! framework 1.x
Common vulnerabilities
XSS
Auth
Passwords
Crypto
testing!
should be avoided by framework
escape all output by default
nowadays, more problems with js
jQuery .html() -> text()
db and other access with binding
think beyond SQL, e.g. xpath
authenticity tokens
two-factor confirmation
SQL
injection
CSRF
XXE
do not accept xml as input
configure parser accordingly
Buffer
overruns
we use Java
Sessions
Logging
Binding
Operations
vs
Development
browser should not be trusted
any input can be mangled
whitelist, not blacklist
Play: secure module
blacklist checks by default
we changed to whitelist
Two-factor
SMS, TOTP, CAP
Google Authenticator
Bank-card based
timezone problems :-)
+ confirmation of operations
cookies are convenient
Secure, HttpOnly
Play: stateless, signed
users not logging out
Brute-force attacks
temp locking of users
usernames not predictable
No captchas
- usability nightmare
no disclosure in error messages
- think like a hacker
later added salt and improved hashing
we needed to migrate them
reverse engineering:
base64 + sha1, no salt,
10 char limit, cp1251 encoding
hashed of course
tied to IP
session cookies with timeout
last login time + city + avatar
full login history
stateless: harder to bypass flows
- drop cookies on front page
request data into objects
convenient for developers
Play: we disabled auto loading of
objects by id
all incoming ids must be checked
no automatic recovery tool
Mobile Auth
SMS can be hijacked
convenience -> PIN
encrypts auth key
decryption cannot be checked on client
auth key is invalidated after 3 tries
decentralized and commercialized
in Russia
you need your own CA
GOST 34-family of algorithms
unique request ids
present in all logs
machine-parseable
log all subsystem api calls
avoid sensitive data
passwords, card numbers, cvv codes
- fraud analysis
tradeoff
or XML Bomb
regression, penetration
FIEO - Filter Input, Escape Output
Doctors and lawyers have licenses
Don't be ignorant
that can be revoked
Help to rebuild the trust
think like a hacker
Paldies!
@antonkeks
Full transcript