So what are the common security vulnerabilities, a professional programmer today should be prepared to face and mitigate during the course of their career? Looking at the available literature, these can be organized into a few specific categories:
- Overflow errors: These include the popular and often abused buffer overflow errors, and the lesser known but still vulnerable arithmetic or integer overflow errors:
- Buffer overflow: Buffer overflows are produced by programming errors that allow an application to write past the end or beginning of a buffer. Buffer overflows allow attackers to take control of systems by gaining access to the applications stack or heap memory by carefully crafted attack data.
- Integer or arithmetic overflow: These errors occur when an arithmetic or mathematical operation on integers produces a result that is too large for the maximum size of the type used to store it.
Integer overflows can create security vulnerabilities if they are not properly handled. In programming languages supporting signed and unsigned integers, overflows can cause the data to wrap and produce negative numbers, allowing the attacker with a result similar to buffer overflows to gain access to heap or stack memory outside the program execution limits.
- Unvalidated/Improperly validated input: A very common security issue with modern web applications, unvalidated input can cause major vulnerabilities, where attackers can trick a program into accepting malicious input such as code data or system commands, which, when executed, can compromise a system. A system that aims to mitigate this type of attack should have filters to check and remove content that is malicious, and only accept data that is reasonable and safe to the system.
Common subtypes of this type of attack include SQL injections, Server-Side Template Injections, Cross-Site-Scripting (XSS), and Shell Execution Exploits.
Modern web application frameworks are vulnerable to this kind of attack due to use of HTML templates which mix code and data, but many of them have standard mitigation procedures such as escaping or filtering of input.
- Improper access control: Modern day applications should define separate roles for their classes of users, such as regular users, and those with special privileges, such as superusers or administrators. When an application fails to do this or does it incorrectly, it can expose routes (URLs) or workflows (series of actions specified by specific URLs containing attack vectors), which can either expose sensitive data to attackers, or, in the worst case, allow an attacker to compromise and take control of the system.
- Cryptography issues: Simply ensuring that access control is in place is not enough for hardening and securing a system. Instead, the level and strength of security should be verified and ascertained; otherwise, your system can still be hacked or compromised. Some examples are as follows:
- HTTP instead of HTTPS: When implementing RESTFul web services, make sure you favor HTTPS (SSL/TLS) over HTTP. In HTTP, all communication is in plain text between the client and server, and can be easily captured by passive network sniffers or carefully crafted packet capture software or devices installed in routers.
Projects like letsencrypt have made life easy for system administrators for procuring and updating free SSL certificates, so securing your servers using SSL/TLS is easier these days than ever before.
- Insecure authentication: Prefer secure authentication techniques on a web server over insecure ones. For example, prefer HTTP Digest authentication to Basic authentication on web servers, as, in the latter, passwords are sent in the clear. Similarly, use Kerberos authentication in a large shared network over less secure alternatives such as Lightweight Directory Access Protocol (LDAP) or NT LAN Manager (NTLM).
- Use of weak passwords: Easy-to-guess or default/trivial passwords are the bane of many modern-day web applications.
- Reuse of secure hashes/secret keys: Secure hashes or secret keys are usually specific to an application or project and should never be reused across applications. Whenever required, generate fresh hashes and or keys.
- Weak encryption techniques: Ciphers used in encrypting communication, either on the server (SSL certificates) or personal computers (GPG/PGP keys), should use high-grade security – of at least 2048 bits and use peer-reviewed and crypto-safe algorithms.
- Weak hashing techniques: Just as in ciphers, hashing techniques used to keep secrets and salts of sensitive data such as passwords, should be careful in choosing strong algorithms. For example, if one is writing an application that requires hashes to be computed and stored today, they would be better off using the SHA-1 or SHA-2 algorithms rather than the weaker MD5.
- Invalid or expired certificates/keys: Web masters often forget to keep their SSL certificates updated, and this can become a big problem, compromising the security of their web servers, as invalid certificates offer no protection. Similarly, personal keys such as GPG or PGP public/private key pairs used for e-mail communication should be kept updated.
- Password enabled SSH: SSH access to remote systems using clear text passwords is a security hole. Disable password-based access and only enable access via authorized SSH keys for specific users only. Disable remote root SSH access.
- HTTP instead of HTTPS: When implementing RESTFul web services, make sure you favor HTTPS (SSL/TLS) over HTTP. In HTTP, all communication is in plain text between the client and server, and can be easily captured by passive network sniffers or carefully crafted packet capture software or devices installed in routers.
- Information leak: A lot of web servers systems—mostly due to open configuration, or misconfiguration, or due to lack of validation of inputs—can reveal a lot of information about themselves to an attacker. Some examples are as follows:
- Server meta information: Many web servers leak information about themselves via their 404 pages, and sometimes, via their landing pages. Here is an example:
404 page of a web server exposing server meta information
By simply requesting for a non-existing page, we came to know that the site seen in the preceding screenshot runs Apache version 2.4.10 on a Debian Server. For a crafty attacker, this is often information enough to try out specific attacks for that particular web-server/OS combination.
- Open index pages: Many websites don't protect their directory pages, and leave them open for world access. This screenshot shows an example:
Open index page of a web server
Open ports: It is a common error to provide world-access to an application's ports running on remote web servers instead of limiting access to them by specific IP addresses or security groups by using firewalls – such as iptables. A similar error is to allow a service to run on 0.0.0.0 (all IP addresses on the server) for a service which is only consumed on the localhost. This makes it easy for attackers to scan for such ports using network reconnaissance tools such as
nmap/hping3, and the like, and plan their attack. - Server meta information: Many web servers leak information about themselves via their 404 pages, and sometimes, via their landing pages. Here is an example:
- Open access to files/folders/databases: A very poor practice is to provide open or world access to application configuration files, log files, process ID files, and other artifacts so that any logged-in user can access and obtain information from these files. Instead, such files should be part of security policies to ensure that only specific roles with the required privileges have access to the files.
- Race conditions: A race condition exists when a program has two or more actors trying to access a certain resource, but the output depends on the correct order of access, which cannot be ensured. An example is two threads trying to increment a numerical value in shared memory without proper synchronization.
Crafty attackers can take advantage of the situation to insert malicious code, change a filename, or sometimes, take advantage of small time gaps in the processing of code to interfere with the sequence of operations.
- System clock drifts: This is the phenomena on where the system or local clock time on a server slowly drifts away from the reference time due to improper or missing synchronization. Over time, the clock drift can cause serious security flaws such as error in SSL certificate validation, which can be exploited by highly sophisticated techniques like timing attacks where an attacker tries to take control over the system by analyzing the time taken to execute cryptographic algorithms. Time synchronization protocols like NTP can be used to mitigate this.
- Insecure file/folder operations: Programmers often make assumptions about the ownership, location, or attributes of a file or folder that might not be true in practice. This can result in conditions where a security flaw can occur or where we may not detect tampering with the system. Some examples are as follows:
- Failing to check results after a write operation, assuming it succeeded
- Assuming local file paths are always local files (whereas, they might be symbolic links to system files for which the application may not have access)
- Improperly using sudo in executing system commands, which, if not done correctly, can cause loopholes, which can be used to gain root access of the system
- Generous use of permissions on shared files or folders, for example, turning on all the execute bits of a program which should be limited to a group, or open home folders which can be read by any logged in user
- Using unsafe serialization and deserialization of code or data objects
It is beyond the scope of this chapter to visit each and every type of vulnerability in this list. However, we will make an earnest attempt to review and explain the common classes of software vulnerabilities that affect Python, and some of its web frameworks in the coming section.