Software Security
Protection against DoS/DDoS attacks
- Bandwidth Management, Protection / Alerting tools. - Serving images, stylesheets and other resources from Content Delivery Networks (CDNs). - Caching commonly accessed resources in-memory or on-disk to reduce database access. - Setting the "Cache-Control" header on rarely-changing resources, so browsers do not request them each time a page is viewed. - Executing long-running processes (like accessing APIs or sending emails) in an asynchronous job queue, rather than in the web-process itself. - Automating web-server deployment, so the number of instances can be scaled up transparently. - Splitting complex applications into micro-services so each component can be scaled separately. - Implementing web-page analytics so high-traffic periods are detected and responded to accordingly.
Worms
A worm is a malicious program that replicates itself in order to spread to other systems. Worms can take the form of executable programs that a user is tricked into downloading and executing. Worms like SAMY (MySpace) make use of cross-site scripting to spread via JavaScript.
Safety (Definition)
Attempt to run a system without being disturbed by its environment or disturbing it. "Workplace safety" requires wearing a hard hat. Protection from natural hazards, like flooding, power failures and fires. Not required to eliminate, but to be noticed with an acceptable level of risk.
OS-Command-Injection / Shell-Command-Injection
Ultimate goal: having full access to the filesystem, being able to issue commands and even install software on a remote system, in order to control the remote system.
UPS
Uninterruptable Power Supply, backed by fuel powered generators.
Disk Forensics
File system is analysed and examined, searching for deleted and / or hidden data. Reducing the amount of data while not missing out relevant data.
Hardware-Security
Hardware effects that might result in security issues. Examples are "row hammer", security issues in special protocols such as BLE or tampering with ATMs or POS-Terminals.
Privilege Escalation vulnerabilities
Horizontal Escalation: attacker panipulating a cookie to impersonate another user -> reputational, legal and financial implications. Vertical Escalation: attacker tempers with an HTML form and POST request to gain administrative access -> interrupt critical functions, compromise application. Any sensitive data passed to the client and returned in a request needs to be varified before making access control decisions.
Protection against SQL Injection: Escaping Inputs
If you are unable to use parameterized statements or a library that writes SQL for you, the next best approach is to ensure proper escaping of special string characters in input parameters. Doubling up the quote character - replacing ' with '' - means "treat this quote as part of the string, not the end of the string". Standard Function in PHP: mysqli_real_escape_string ( mysqli $link , string $escapestr ) : string Still risky: def current_user(id) User.where("id = " + id) end
Availability
In most cases IT is crucial for a business to be able to run. Availability is a security and a safety requirement. Electrical power etc. it is a safety requirement. Software not crashing under attack or being resilient to dDoS-type attacks, is a security requirement. Attacks include: cutting power lines, ransomware, SQL injection (dropping Amazon.com shop data tables).
Unencrypted Communication -> Man-in-the-Middle attack
Insufficient encryption can cause man-in-the-middle attacks. Use HTTPS whenever transmitting sensitive information (TLS - Transport Layer Security protocol). Insecure Wi-Fi hotspots are one way hackers can take advantage of unencrypted communication. They may also try to sniff traffic within a network, and if they get access, inspect traffic going through compromised edge devices. Any point between a server and the user's browser is a potential weak-spot. Given the non-deterministic nature of internet routing, a lot of opportunities present themselves to an attacker.
Reflected XSS attack
Less dangerous than stored XSS attacks, which cause a persistent problem when users visit a particular page, but are much more common. Any page that takes a parameter from a GET or POST request and displays that parameter back to the user in some fashion is potentially at risk. A page that fails to treat query string parameters as untrusted content can allow the construction of malicious URLs. An attacker spreads these malicious URLs in emails, in comments sections, or in forums. Check: Search results, Error pages, Form submissions, all pages, not only those that write to the data store! -> properly escaped displays back to the user
Protection against XSS (Cross-site scripting): Escape Dynamic Content
Make sure any dynamic content coming from the data store cannot be used to inject JavaScript on a page. The attacker abuses an editable field by inserting some JavaScript code, which is evaluated in the browser when another user visits that page. Making use of the improper treatment of dynamic content coming from a backend data store. -> Escape all dynamic content, browser treating content as "contents" of HTML tags, as opposed to raw HTML. Replacing significant characters with the HTML entity encoding, so it will never be treated as executable code by the browser. Examples: ": " #: # &: & ': ' (: ( ): ) /: / ;: ; <: < >: >
Protection against Clickjacking Attack
Making sure a page cannot be wrapped in an iframe by a malicious site. This can be done by giving the browser instructions directly via HTTP headers, or in older browsers by using client-side JavaScript (frame-killing). X-Frame-Options in HTTP headers: values: DENY, SAMEORIGIN, ALLOW-FROM *uri* Content-Security-Policy in HTML5 HTTP header: Content-Security-Policy: frame-ancestors 'none' (instead of none: self / *uri*) Frame-Killing: if (self == top) {document.documentElement.style.display = 'block';} else {top.location = self.location;} #break out of frame
Non-Repudiation
Once a transaction is done, neither party should be able to deny their actions. Online banking example: both the customer nor the bank are bound by their transactions, neither is able to deny it has participated.
Reverse Shell
Shell session established on a connection that is initiated from a remote machine. A type of shell in which the target machine communicates back to the attacking machine. The attacking machine has a listener port on which it receives the connection, which by using, code or command execution is achieved
Protection against XML External Entities (XXE) attacks
- Disable inline DTDs in your XML parsing library: Many XML parsing libraries do not disable this feature by default. Make sure the XML parser configuration disables this feature. - Limit the Permissions of a Web Server Process: Run server processes with only the permissions they require to function - follow the "principle of least privilege". This means restricting which directories in the file-system can be accessed. Consider running in a "chroot jail" if running on Unix.
Cloud Forensics
Cloud environment: machine and its data potentially moving around several host systems with a certain risk of the system being switched off and deleted. Other than physical devices it cannot be seized and thus controlled. Another level of complexity through virtual networks.
LDAP-Injection
Code injection technique used to exploit web applications which could reveal sensitive user information or modify information represented in the LDAP (Lightweight Directory Access Protocol) data stores. Exploiting a security vulnerability in an application by manipulating input parameters passed to internal search, add or modify functions. Occurs when user input is not properly sanitized and then used as part of a dynamically generated LDAP filter. This results in potential manipulation of the LDAP statements performed on the LDAP server to either view, modify, or bypass authentication credentials All of the client supplied input must be checked / sanitized of any characters that may result in malicious behavior. The input validation should verify the input by checking for the presence of special characters that are a part of the LDAP query language, known data types, legal values, etc. White list input validation can also be used to detect unauthorized input before it is passed to the LDAP query.
Weak Session IDs - Risks and Protection
Weak session IDs can expose users to having their sessions hijacked. If session IDs are picked from a small range of values, an attacker only needs to probe randomly chosen session IDs until they find a match. - Use Built-In Session Management: Modern frameworks implement safe, unguessable session IDs. - Tamper-Proof Cookies: Sign cookies. The server will be able to tell if the cookie has been manipulated since it was sent to the browser with the "Set-Cookie" header.
Badstore (ISO-Image)
Web shop that's badly programmed. Dedicated to helping understand how hackers prey on Web application vulnerabilities, and show how to reduce exposure. Badstore demonstration software is designed to show common hacking techniques.
XPath-Injection
XPath is a way to access and search XML-documents often used instead of databases. Vulnerabilities arise when user-controllable data is incorporated into XPath queries in an unsafe manner. An attacker can supply crafted input to break out of the data context in which their input appears and interfere with the structure of the surrounding query.
Protection against SQL Injection: Principle of Least Privilege
Each process or software component can access and affect only the resources it needs. Applying restricted privileges ("levels of clearance") can help mitigate a lot of the risk around injection attacks. Reduce the permissions of the application at runtime, so it can at most edit data, but not change table structures (only during release windows). In a SQL database, this means making sure your production accounts can only execute DML statements, not DDL statements.
File Upload Vulnerabilities
Easy way for an attacker to inject malicious code into an application. Sophisticated hackers typically exploit a combination of vulnerabilities when attacking a site - uploading malicious code to a server is often step one. Any input coming from a user ought to be treated with suspicion until it has been guaranteed to be safe. This is particularly true of uploaded files, because applications will typically treat them as a big blob of data.
Software-Security
Addresses all security issues within software. In most cases software installed upon a system by a user or administrator. Software in firmware (embedded/hardware) is considered to be software. Quality Management: coding standards, code reviews, data flow analysis, input sanitization, automated tests Tools: CMS, PHPMyAdmin, phpinfo()
Directory Traversal vulnerabilities
Allow attackers to access arbitrary files on a system. They tend to occur in older technology stacks, which map URLs too literally to directories on disk. If a site is indexed on Google, and has URLs that pass file names in the query string, they are likely advertising a potential vulnerability to attackers (searching for tell-tale URLs).
Password Mismanagement
Ensuring strong authentication is a mix of pushing users and programmers into good habits. Attackers are constantly trying to find ways to bypass authentication. Good Practice: Using 3rd Party Authentication, Ensure Password Complexity (length, mixed-case, blacklist), Password Resets via Email, Confirm Old Password On Reset when logged in, Prevent Brute-Forcing (prevent User Enumeration), Store Passwords With A Strong Hash (no plain-text), Salted, Timeout Sessions After Inactivity, Logout Function, Use HTTPS for Secure Communication
Virtual Computing security
Escaping the virtual machine and thereby attacking the host and / or other guests on the same host. Some attack techniques are similar to attacking OS, hardware and software. More services moving to virtual machines and the cloud. Operating systems such as Qubes OS claiming they would increase security by using virtualisation techniques.
Out-Of-Bounds-Read
Stands for a security issue, where more data is read than stored. This leads to information disclosure. A very prominent example was heart-bleed. A "heart-beat" feature was implemented for TLS. In IT "heart-beat" means checking whether a system is up and running and reachable over the network. In this case a specific SSL message was constructed, where the client could send an arbitrary amount of data to the server. All it needed to do was to specify the size of the message in the header of the heart-beat packet. - Network Intrusion Detection System (NIDS) to identify the intrusion.
Protection against SQL Injection: Password Hashing
Storing unencrypted passwords (in "plain-text") is a major security flaw in itself. Applications should store user passwords as strong, one-way hashes, preferably salted. This mitigates the risk of malicious users stealing credentials, or impersonating other users.
Network-Security
(Personal) Firewall only reduces critical network traffic, it helps protecting computers. Attacks: distributed Denial of Service (dDoS) or sniffing data in transmission.
Protection against Malicious Redirects
- Disallow Offsite Redirects: Prevent redirects to other domains by checking the URL being passed to the redirect function (relative paths starting with a "/", rejecting "//"). - Whitelist permitted external redirects. - Check the Referrer When Doing Redirects: Check that the "Referer" in the HTTP request matches the same domain when preforming a redirect. - Check Client-Side Code (window.location), Interstitial Pages "you will be automatically redirected in 5 seconds" and Aggregator Sites (click-counting) too!
Protection against Unencrypted Communication
- Encryption prevents an attacker from intercepting or tempering traffic sent between a page and its users. Cheap and easy to implement, and an absolute necessity when transmitting sensitive data. - SSL/TLS Certificates (HTTPS port 443 vs. HTTP port 80): install and configure a web server to use it. - Forceing a web server to elevate to a secure connection: whenever a user is authenticating or establishing a session. Set cookies to "secure" - that way, sessions can only be established over HTTPS. <session-config> <cookie-config> <secure>true</secure> </cookie-config> </session-config>
Protection against Reflected XSS attacks
- Escape Dynamic Content: Escape all dynamic content coming from a data store, so the browser knows it is to be treated as the "contents" of HTML tags, as opposed to raw HTML. - Whitelist Values: If a particular dynamic data item can only take a handful of valid values, the best practice is to restrict the values in the data store, and have your rendering logic only permit known good values. - Implement a Content-Security Policy: Content-Security-Policy: script-src 'self' https://apis.google.com or: "report-uri" directive in policy header: browser will notify of any policy violations, rather than preventing inline JavaScript from executing.
Protection against Privilage Escalation
- Keep critical information on the server side: only send session IDs to the client (extra obligations on server). - Tamper-proof the data sent to the client: using a digital signature. Many web frameworks allow to encode session state, and accompany it with a digital signature which must be sent back with the data. Upon receipt of the returned data, the digital signature is recalculated. Any modifications will result in a different signature, indicating the data has been tampered with, and must be discarded. Loss of site responsiveness when too big. - Encrypt the data sent to a client: opaque and tamper-proof, encoding and encrypting the data. Decryption with ever request and re-encrypted with every response leads to computational overhead.
Protection against User Enumeration attacks
- Login: return a generic "No such username or password" message when a login failure occurs. - Password Reset: make sure your "forgotten password" page does not reveal usernames. Ask to enter an email address, send an email when it exists. - Registration: avoid telling which usernames are taken. Send password reset email when anew registration. Protect process with CAPTCHA. - Profile Pages: only visible to other logged in users. Make pages look indistinguishable to non-existent.
Protection against Cross-Site Request Forgery (CSRF or XSRF)
- REST (Representation State Transfer): A series of design principles that assign certain types of action (view, create, delete, update). Following REST-ful designs will keep a code clean and help a site scale. REST insists that GET requests are used only to view resources. Keeping GET requests side-effect free will limit the harm that can be done by maliciously crafted URLs. An attacker will have to work much harder to generate harmful POST requests. - Anti-Forgery Tokens (strongly random number): To ensure handling only valid HTTP requests, you need to include a secret and unique token with each HTTP response in a hidden HTML form field, and have the server verify that token when it is passed back in subsequent requests that use other methods than GET. - Cookies are sent with the SameSite Cookie Attribute: Instruct browsers to control whether cookies are sent along with the request initiated by third-party domains. Set-Cookie: CookieName=CookieValue; SameSite=Lax; -> friendlier user-experience - but make sure GET requests are side-effect free! (or set to "Strict"). - Additional Authentication for Sensitive Actions.
Protection against File Upload Vulnerabilities
- Segregate Uploads: Making sure uploaded files are kept separate from application code. Consider using cloud-based storage or a content management system to store uploaded files. Even storing uploaded files on a remote file server or in a separate disk partition helps, by isolating the potential damage a malicious file can do. - Ensure Upload Files Cannot Be Executed: OS should not treat files as executable code, no permission for web server to execute files. Using a Unix-based operating system, uploaded files are written without the "executable" flag in the file permissions. - Rename Files on Upload: Rewriting or obfuscating file names will make it harder for an attacker to locate a malicious file once they have uploaded it. - Validate File Formats and Extensions on server-side (Whitelist) -> validating Content-Type Header is unsafe. Others: Virus Scanner, Checking File Size (DoS attack), Sanitize Filenames (overlong -> buffer overflow, special characters), avoid or check compressed files (zip bomb)
Possible motivation using XSS (Cross-site scripting)
- Spreading worms on social media sites. - Session hijacking (sending the session ID to a remote site under the hacker's control, allowing him to impersonate that user by hijacking a session in progress). - Identity theft (wher a user enters confidential information such as credit card numbers into a compromised website, these details can be stolen using malicious JavaScript). - Denial of service attacks and website vandalism. - Theft of sensitive data, like passwords. - Financial fraud on banking sites.
Protection against Directory Traversal
- Use a Content Management System (CMS). - Use Indirection: using indirection to label files. Each time a file is uploaded, construct a "friendly" name for this on the site. When the file is accessed, perform a lookup in a data-store to discover the actual file path. This effectively white-lists valid names, and avoids the fragility of passing around raw file paths. - Segregate Documents: hosting documents on a separate file-server or file partition, or in cloud storage. This will allow to prevent mixing public documents and more sensitive material. - Sanitize Filename Parameters: sanitize the file names coming in from HTTP requests, checking for ("back-tracking"-) paths, such as: ../ - Run with Restricted Permissions: run your server processes with only the permissions that they require to function - the "principle of least privilege". Make sure the server process can only access the directories it needs. Using Chroot Jail on Unix.
Protection against Buffer Overflow
- Use secure C and C++ functions: fgets (not gets), strncpy (not strcpy), strncat (not strcat), snprintf (not sprintf). - Deploy security patches as soon as available. - Automate build and deployment process (write deployment scripts for web-servers and language runtimes, and retain copies of deployment logs). - Look out for security announcements for tools in use (in forums, follow vendors, sign up for mailing lists).
Chroot Jail
A "change root" operation changes the apparent root directory for a running process and its children. It allows to run a process with a root directory other than /. One can run a program and specify its root directory as /home/user/jail. In this case, the program's root directory is actually /home/user/jail. The program would not be aware of, or able to access, any files above this directory in the hierarchy. This artificial root directory is called a "chroot jail". Its purpose is to limit the directory access of a potential attacker. It locks down a given process and any user ID it is using so that the user sees only the directory that the process is running in. To the process, it appears that it is running in the root directory. The chroot directory must be populated with all required program files, configuration files, device nodes, and shared libraries at their expected locations. Process only as normal user, not root! Saved UID, correctly returning rights. Doesn't defend against intentional tampering by privileged (root) users. Chroot root user can still create device nodes and mount the file systems on them
Salted Hash Passwords
A hashing algorithm is a one-way transformation that obscures the original input, but can be used to test if the input is entered correctly again. By saving passwords in hashed form, even an attacker (or a malicious employee!) who gets access to a database cannot make use of the account details. Still vulnerable to an attacker able to generate a rainbow table - a list of pre-calculated hashes of common passwords. This type of lookup attack can be defeated by adding salt to the hash - an element of randomness that will make the same input create a different hash, but still usable to check the correctness of the input when entered again.
Zip Bomb (Zip of Death / Decompression Bomb)
A malicious archive file designed to crash or render useless the program or system reading it. It is often employed to disable antivirus software, in order to create an opening for more traditional viruses. The archive is crafted so that unpacking it (e.g., by a virus scanner in order to scan for viruses) requires inordinate amounts of time, disk space or memory. -> 42.zip
Cross-site scripting (XSS)
A vulnerability in dynamic web pages that allows an attacker to bypass a browser's security mechanisms and instruct the victim's browser to execute code, thinking it came from the desired website. Very common. XSS vulnerabilities permit a malicious user to execute arbitrary chunks of JavaScript when other users visit the site. Severety of attack depends on the sensitivity of the data being handled by a website.
Command Execution / Remote Code Execution Attack
An attacker can execute arbitrary code on a server. Command injection vulnerabilities often occur in older, legacy code, such as CGI scripts. A major security lapse, and the last step to complete system takeover. After gaining access, an attacker will attempt to escalate their privileges on the server, install malicious scripts, or make the server part of a botnet to be used at a later date.
Software Forensics
Analysing security issues related to software. Examples: identifying evidence of a HTML injection to a web shop via finding the buffer overflow that was used to run some shell code; reverse engineering malware
Injection
Attack where code is injected into a running process and executed with the rights of this process. Web security: plain-text code rather than compiled code (when attacking regular applications).
Session Fixation vulnerabilities (Session Hijacking) - Definition and Protection
Attacker sets a user's session ID to one known to them, for example by sending the user an email with a link that contains a particular session ID. The attacker now only has to wait until the user logs in. This allows hackers to bypass an authentication scheme. A secure session implementation on a site is key to protecting users. - Don't Pass Session IDs in GET/POST Variables: Make crafting of malicious URLs impossible, no leak of session ID (through out-bound link -> Referer header, browser history, bookmarks or logs on servers). Pass Session IDs in HTTP cookies instead (stateless HTTP). - Regenerate the Session ID at Authentication (login). - Accept Only Server-Generated Session IDs. - Timeout and Replace Old Session IDs (leakage). - Implement a Strong Logout Function (obsolete IDs). - Require a New Session when visiting from Suspicious Referrers.
Broken Authentication and Session Management
Attackers use leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to temporarily or permanently impersonate users. Issues: Hardcoded credentials, Stored plain-text credentials, User Enumeration, Too short (default) passwords.
HTML-Injection
Attempt to alter the HTML appearance of a web page by inserting additional HTML-code. Changes data displayed or lure users into entering credentials. Requires creativity. Relevant: iframes, UTF-8 overencoding, htmlspecialchars() instead of htmlentities(), "magic_quotes_gpc" (before PHP 5.4.0).
Denial-of-Service (DoS) attack
Attempt to make a web service or website unavailable by flooding it with network packets. Sophisticated attacks involve sending malicious traffic from many different (or spoofed) IP addresses. Online applications tend to have a limited bandwidth. - SYN Flood: host sends flood of TCP/SYN packets, but fails to respond to replied "Acknowledge" messages. This leaves half-open connections that can saturate the number of available connections the server can make. - Slow Read: sends legitimate application layer requests, but returns responses very slowly, exhausting the server's connection pool. - Ping of Death: deliberately malformed data packets. - Reflected Attacks: flooding 3rd party service with forged packets, responses flood fake reply address.
Mitigating security risks
Avoiding: switching the computer off, not providing a computer or smartphone (if unnecessary). Malware scanners: finding the infection rather than making it impossible to infect a system. Stickers over web cams: control whether they are used or not. Plugged in fake microphones: "short circuit" a computers built-in microphone. Firewalls: as with the Blaster and Sasser worms, since they only prevented the worm to spread. Spam filters. Address space layout randomisation: does not resolve the reason for a buffer overflow, but might require more hacking skills to actually perform it. Fixing program code, establishing quality management.
Security (Definition)
Building a system, that resists to at least some extent intentional malicious interaction from humans or other systems. "Workplace security" implemented with a "bouncer" when entering the company. Unable to access, modify, delete or add data, nor inject arbitrary code into programmes, in a broader meaning that a programme should stay within the execution path intended by its programmer. Program layer: avoiding all the well known attacks such as buffer overflows or code injections. Hardware layer: preventing side-channel attacks, avoiding data extraction by removing or adding devices, such as keyloggers. Operating system level: protects running processes from each other. Network layer: authenticity, confidentiality, integrity and non-repudiation.
Network Forensics
Captured network data is analysed to identify attackers and their methods. Attackers are also directed to specific environments designed to observe them, such as honeypots. Challenges: anonymisation and massive amounts of data.
Remote Shell (rsh)
Command line computer program that can execute shell commands as another user, and on another computer across a computer network. The remote system to which rsh connects runs the rsh daemon (rshd). The daemon typically uses the well-known Transmission Control Protocol (TCP) port number 514. The rsh protocol is not secure for network use, because it sends unencrypted information over the network, among other reasons. Some implementations also authenticate by sending unencrypted passwords over the network. rsh has largely been replaced with the secure shell (ssh) program, even on local networks.
DVWA
Damn Vulnerable Web Application - a rather easy to hack PHP/MySQL web application. Its main goals are to be an aid for security professionals to test skills and tools in a legal environment, help web developers better understand the processes of securing web applications and aid teachers/students to teach/learn web application security in a class room environment.
Integrity
Data remains unchanged, either during transmission or data stored somewhere. Supported by cryptographically safe hash-algorithms and signatures.
Protection against SQL Injection: Object Relational Mapping (ORM)
Developers will rarely have to write SQL statements in their code, using parameterized statements under the hood. Careful when writing SQL statements by concatenating strings! Good example: def current_user(email) # The 'User' object is an Active Record object, that has find methods auto-magically generated by Rails. User.find_by_email(email) end Bad example: def current_user(email) # This code would be vulnerable to a maliciously crafted email parameter. User.where("email = '" + email + "'") end
Protection against SQL Injection: Parameterized Statements
Good practice: the parameterized string and the parameters are passed to the database separately, , which allows the driver to correctly interpret them. Bad practice: the full SQL statement is constructed before the driver is invoked, meaning we are vulnerable to maliciously crafted parameters. Good example: String sql = "SELECT * FROM users WHERE email = ?"; ResultSet results = stmt.executeQuery(sql, email); Bad example: String sql = "SELECT * FROM users WHERE email = '" + email + "'"; ResultSet results = stmt.executeQuery(sql);
Authenticity
Identifying ("authenticating") partners, usually in a communication setup. Shared secret (such as a passphrase, birthday or address) is being asked, not very secure. ID card or passport more secure, needs criminal energy to fake. IT network: certificates which were signed by a (more or less) trustworthy authority. General IT: shared secrets, biometrics or authentication devices such as smart cards, often combined.
Protection against XSS (Cross-site scripting): Whitelist Values
If a particular dynamic data item can only take a handful of valid values, the best practice is to restrict the values in the data store, and have the rendering logic only permit known good values. For instance, instead of asking a user to type in their country of residence, have them select from a drop-down list.
User Enumeration attack
If an attacker can abuse an authentication function or probe a website or API to test whether a username exists and harvest the list of usernames. Sometimes login pages have different error messages for unrecognized usernames and incorrect passwords. Other times checking for wrong usernames, passwords (or the combination of both) varies in duration. Scripts can test for usernames. Some password reset pages give hints if the username exists or not. Same with registration pages. Also profile pages with usernames in the URL are dangerous. Next step: brute-force common passwords or use Email addresses together with Social Engineering to trick users into revealing their password.
Principle of Least Privilege
It is a good practice to run your server processes with only the permissions that they require to function. This can help limit the impact of command injection vulnerabilities as a second line of defense. Make sure each web server process can only access the directories that it needs, and narrow down the directories in which they write or execute files. Consider running the process in a "chroot jail" if you are running on Unix. This will limit the ability of maliciously injected code to "climb out" of a directory.
Script-Language Command Injection
Main effects on the server (rather than client). Used to run arbitrary commands on the server. But can also change the look and feel of a page and therefore for tricking a user into phishing. Possible with any scripting language: PHP, Perl, Python (different syntax only).
SQL-Injection
Most common way of attacking web applications. Code injection technique, used to attack data-driven applications, in which malicious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). Exploits a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. Allows attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server.
Buffer Overflow attack
Occurs when a process tries to write too much data into a fixed length block of a contiguous memory (buffer). Used for crashing a web-server or executing malicious code. Low-level languages (C, C++, Assembly) require the application itself to check the buffer length (no managed memory, as in high-level languages). No-Op Sled: The memory space gets filled with as many "no operation" instructions as possible, followed by the injected code. When the program's execution context lands on these no-ops, it will skip them and finally execute the injected code.
Blind SQL injection
Occurs when the database is vulnerable but configured to suppress error messages. It overcomes the lack of error messages. Without the error messages that facilitate SQL Injection, the attacker constructs input strings that probe the target through simple Boolean SQL expressions. The results are usually not visible to the attacker.
Protection against SQL Injection: Third Party Authentication
Out-sourcing the authentication workflow of an application. Facebook, Twitter, and Google all provide mature OAuth APIs, which can be used to let users log into a website using their existing accounts on those systems. This saves an application developer from rolling own authentication, and assures users that their passwords are only stored in a single location. Might frustrate users with privacy concerns.
Confidentiality
Protecting data interception by a 3rd party during transmission. Encryption and Steganography protect messages in transit.
Protection against SQL Injection: Escaping Inputs
Reject inputs that look suspicious out of hand, while taking care not to accidentally punish legitimate users. For instance, your application may clean parameters supplied in GET and POST requests in the following ways: - Check that supplied fields like email addresses match a regular expression. - Ensure that numeric or alphanumeric fields do not contain symbol characters. - Reject (or strip) out whitespace and new line characters where they are not appropriate. - Client-side validation (i.e. in JavaScript) is useful for giving the user immediate feedback when filling out a form, but is no defense against a serious hacker. Most hack attempts are performed using scripts, rather than the browser itself. Suspicious input: single quotes, calculations 1=1--
IT Forensics
Security incidents as well as "cyber" crime is investigated, with the aim of identifying any digital evidence. Ranges from attacks on computers to real world crime, where digital devices might provide evidence, such as a fit-bit-activity tracker in an alleged rape, GSM network data in a murder investigation, or digital video footage of road accidents. Computer systems need to be analysed, its data validated and put into context, in a way that a court would accept and understand it.
Broken Access Control - Definition and Protection
Security through obscurity (hiding) is best avoided. Correctly applied access control rules are key to keeping data secure. Hidden URLs can be guessed. - Authentication: correctly identifying a user when they return to the application. - Authorization: deciding what actions a user should and should not be able to perform. - Permission Checking: evaluating authorization at the point-in-time when a user attempts to perform actions. - Design and document access control scheme upfront. - Attempt to centralize access control decisions. - Test access control critically. - Content Management Systems (CMS). - LDAP (role- and group-based authorization across multiple applications).
Protection against XSS (Cross-site scripting): HTTP-only Cookies
Session-hijacking attacks can use malicious JavaScript to steal the cookie containing the user's session ID. There is rarely a good reason to read or manipulate cookies in client-side JavaScript, so consider marking cookies as HTTP-only, meaning that cookies will be received, stored, and sent by the browser, but cannot be modified or read by JavaScript.
Protection against XSS (Cross-site scripting): Sanitize HTML
Some sites have a legitimate need to store and render raw HTML, especially now that contentEditable has become part of the HTML5 standard. If a site stores and renders rich content, it needs to use a HTML sanitization library to ensure malicious users cannot inject scripts in their HTML submissions.
Operating system security
Special layer between the user space, where applications run. Same methods used as in software security, with only a few specialities.
Protection against Command Execution / Remote Code Execution
Taking great care when designing how a web server interacts with the underlying operating system. If an application calls out to the operating system, command strings need to be securely constructed. Use APIs wherever possible - only use shell command line calls where absolutely necessary, try to avoid them. Escape Inputs Correctly, sanitize untrusted input correctly, restrict input by testing against a regular expression of known safe characters (like alphanumeric) -> potentially malicious characters: ; & | ` Restrict the Permitted Commands: string literals rather than user input (whitelist permitted input values or enumerate in a conditional statement). Perform Thorough Code Reviews, Run with Restricted Permissions (principle of least privilege).
Social Engineering
Targets the human rather than the machine, to gain information and / or access to computers and networks, usually in order to exfiltrate data. Highly interdisciplinary, found in fraud, psychotherapy, criminalistics, social sciences and educational sciences. Used in conjunction with malware, especially Trojans.
Protection against XSS (Cross-site scripting): Escaping HTML
The PHP echo command does not escape HTML by default, which means that any code like the following, which pulls data directly out of the HTTP request, is vulnerable to XSS attacks. Be sure to use the strip_tags function or the htmlspecialchars function to safely escape parameters. Java: c:out C#: <%: React: {dynamic content written into curly brackets}
Cross-Site Request Forgery (CSRF or XSRF) [pronounced "sea-surf"]
Tricking a user's browser into performing an unwanted action from a third-party site. XSRF exploits the trust a site has in the user's browser. Any function that users can perform deliberately is something they can be tricked into performing inadvertently using CSRF. Servers are triggered by forged HTTP requests, through GET or non-GET requests. Possible motivation: - Steal confidential data. - Spread worms on social media. - Install malware on mobile phones.
Clickjacking Attack
Tricks web users into performing an action they did not intend, typically by rendering an invisible page element on top of the action the user thinks they are performing. Possible motivation: - Harvest login credentials, by rendering a fake login box on top of the real one. - Trick users into turning on their web-cam or microphone, by rendering invisible elements over the Adobe Flash settings page. - Spread worms on social media sites. - Promote online scams by tricking people into clicking on things they otherwise would not. - Spread malware by diverting users to malicious download links.
Hardware Forensics
Trying to identify how faulty hardware contributed to an incident or whether hardware was modified or tampered with. Includes analysing devices, such as unsoldering memory chips and analysing their content, called "chip-of-forensics". Understanding of electrical engineering, micro controllers, assembler programming and software-security.
Distributed Denial of Service (DDoS) attack
Using numerous computers (network of bots) to attack the target network from numerous launch points. Often unknowingly on 3rd party machines (IoT risk) via malware, orchestrating massive waves of requests to make a service unavailable. Motivation: extortion, revenge, politics, mischief
Open Redirect
When an application redirects the user to an URL supplied from an untrusted source, without checking the validity of that URL. Often used in phishing attacks, where malicious links are send out, tricking users into visiting a harmful site. Supposedly trustworthy links that redirect to malicious sites. Encoded, slightly hidden redirect parameter (login page of trustworthy page might redirect to "next"): www.example.com?_g=DernKFjelgnne&vid=iguana-party&referrer=email&next=http%3A%2F%2Fwww.haxxed.com
Protection against XSS (Cross-site scripting): Implement a Content-Security Policy
Whitelisting the URIs from which scripts can be loaded, implicitly states that inline JavaScript is not allowed. Content-Security-Policy: script-src 'self' https://apis.google.com or <meta http-equiv="Content-Security-Policy" content="script-src 'self' https://apis.google.com"> Check if inline scripts are still active by making use of CSP Violation Reports. By adding a report-uri directive in your policy header, the browser will notify a developer of any policy violations: Content-Security-Policy-Report-Only: script-src 'self'; report-uri http://example.com/csr-reports
XML External Entities (XXE) attack
XML provides the option to include files while parsing a XML file. A XXE makes use of this feature and modifies a request in such a way that an external file is included, be it an XML file or /etc/passwd. XML External Entity attacks allow a malicious user to read arbitrary files on a server. Getting access to the server's file system is often the first step an attacker will take when compromising a system. Unless you deploy a intrusion detection system, you will often not know it is occurring until it's too late.
