FIT3SQA – Software Quality Assurance

Lecture 9

Security Engineering
+ Security Guidelines

Faculty of Information Technology

Hanoi University
 Security considerations
• Security should be considered from the
beginning, not added as a layer at the end.
• Security layers:
– Antivirus software
• Protection against known malwares, spywares
– Firewall/IPS
• Block unauthenticated network access.
• Security layers cannot protect from bug/glitch
exploitations.
 Antivirus Software
• On user’s machine
– Prevents malwares from stealing application data
– Not always available
• On server machine
– Prevents malicious codes from running on the server
– Prevents backdoor and file corruptions by malwares
• Rules-based antivirus programs only detect
known threats
• AI-based antivirus programs can sometimes have
false alarms
 Firewall/IPS
• Hardware: placed at network gateways
– Filters traffic in and out of local network
– Protects all machines inside the network
• Software: runs on servers
• Firewall blocks traffic according to rules
– Protocol, address, port, source/destination…
• IPS blocks traffic according to signatures
– IPS recognizes patterns in packet headers and content
 Security considerations
• Security layers cannot protect from:
– Bugs that give users the ability to access sensitive
information
– Logic flaws that attackers can exploit
– Unencrypted data sent over insecure protocols
– Unencrypted cookies or application data files
– Glitches in application that allows user to
inject/upload malwares or customized codes
 Desktop application threats
• Attacker can read memory content
– Hard-coded admin passwords can be read from
memory.
– Sensitive data such as database connection
information can be read from memory.
– Encryption key stored in a variable can be read
from memory.
• Attacker can modify memory content
– Attacker will use the least secure OS to do it.
 Mobile & Web threats
• Mobile
– The same threats as desktop apps
– Rooted devices can do things without restriction.
• Web
– Requests can be sent from anywhere.
– Cookies can be read.
– Browsers can be modified.
– Packets sent over network can be captured.
 General guidelines
• Think of all the possible things your code does
• Follow guidelines for your programming language
and software type
– Official tutorials and docs always recommend best
practices.
• Reuse trusted code (libraries, modules, etc.)
– From reputable publishers
• Write good-quality, readable code
– Logically organized and readable code also tend to be
more secure.
 Best practices
• Display generic error messages
– Error messages should not reveal details about the internal
state of the application.
– Do not include unnecessary information in error messages.
• Handle all exceptions
– Throwing exceptions can expose sensitive application data.
• Log important user activities
– Log data changes, user authentications.
– Do not log sensitive data such as passwords.
Code exposure through error message

Image Credit: troyhunt.com

 Best practices
• Use HTTPS Everywhere
– HTTPS protects all HTTP requests and responses
from the Transport Layer.
– Even URLs cannot be captured from HTTPs
packages.
• Properly set file access/execution permissions
– Windows “Security” tab in file/folder properties.
– chown, chmod commands in Linux
HTTP packet capture password

Image Credit: samsclass.info

 Best practices
• Store encrypted passwords (using hash)
– Strong, Salted hash.
– It’s not possible to restore a forgotten password.
– It’s only possible to reset a password.

• Use tokenization to reduce data exposure

– A token is an encrypted string which is linked to
user session on the server.
– A token is a proof of authentication.
 Hashed passwords

Original Hashed Algorithm Salted

quandd $2y$10$.ogUaBe63bWOwYFbv0nwHOmAQ3Vt2 bcrypt Yes
NsZrbFXJsRrXeELBIz1k.woW
quandd 30896c70366020d7e15f7b9f663fafca MD5 No
quandd adfbc7280fa28504a92251d3f9818a703612d321 SHA-1 No
quandd 3643ae9db78d16e1e38c06776d8f9ea7160e930 SHA-256 No
4021fa5ec7e0555f331ebea29
quandd 0f0f1ae3b0d665e0080078bfa82f8c5a438437556 SHA-512 No
574c6d94dac2baf6d8488b810314765146a21cc9
556e74d51a7f9b475c6753803a24c770e086d59
b28953c8
 Best practices
• Strengthen the infrastructure
– Configure software and hardware infrastructure
according to security best practices.
• Educate team and customers on security
– Provide team with security training.
– Provide customers with security guidelines in
documents and/or training courses.
 Best practices
• Do not hard-code credentials
– E.g. database passwords, admin passwords.
– Convenience leads to security flaws.
• Enforce password policy
– Do not allow users to use weak passwords.
– General rules for a strong password:
• Long, mixing letters, digits & symbols
• Not related to personal info
• Avoid using dictionary words or meaningful phases
Hack Tool: Memory Editor

Image Credit: cheatengine.org

 Best practices
• Account Lockout
– Lock account after several incorrect passwords.
– Helps protect against Brute Force Attacks.
• Run applications with minimal privileges
– Optimization is about giving only what is
necessary.
• Set cookies/session/password expiration
– Any kind of encryption is only valid for a certain
amount of time (the time it takes to break it).
Security feature: account lockout

Disable a feature after some failed attempts

Image Credit: ios.gadgethacks.com

 Best practices
• Use up-to-date database access method
– Parameterized SQL queries, Prepared
Statements… are the current methods.
– Helps protect against SQL Injection Attacks.
• Use appropriate data encoding
– E.g. plain text should be encoded differently from
rich text, data in URLs should be encoded
differently from data used in JavaScript.
– Helps protect against XSS Attacks.
 Best practices
• Prefer whitelist over blacklist
– It is safer to block all unexpected things.
• Generate and use trusted token
– Imagine you want to prevent attackers from automatically
submit data to your form.
– On the server side, you generate a random string and save
it in the user’s session.
– You convert the string to image format with some
alterations so that robots are unable to read it.
– Show the captcha and ask the user to type it in.
 Secret is the foundation of security.
 Best practices
• Validate all inputs
– Uploaded files.
– Input fields.
– The source of inputs (e.g. Referrer URL, the source
application, the input device…)
• Choose safe defaults
– Default values such as default passwords, default
privileges should be safe.
 Best practices
• Keep bottlenecks as light as possible
– Request handler, login server, load balancer.
– These bottlenecks should use very little resources
to reduce the impact of DDoS.
• In web application, do not trust client-side
validation.
– Client-side validations can be bypassed easily.
 Best practices
• Race condition
– Parallel processes try to change a single value.
– There should be some kind of locking mechanism.
• Be careful with system shell calls
– There are built-in functions in programming
languages to allow interaction with the OS.
– If hackers manage to inject some commands in
the shell call, he might be able to take control of
the user’s system.