Search the Community

Web applications are critical to the enterprise infrastructure. Companies rely on them to communicate with partners, clients, shareholders and others, as well as store corporate information, share files, and conduct a host of other operations. These applications are convenient, as their functionality is dependent upon online browsers. However, web applications may have security weaknesses that can expose a single user or the entire organization to multiple threats. Cyber criminals have been focusing on the web in recent years and the trend continues to grow. Cyber attacks are becoming high-profile, getting more sophisticated, and increasing in frequency. According to the Gartner Group, 75 percent of cyber attacks and web security violations occur through Internet applications. Regardless of the development of the application being outsourced or in-house, adversaries examine the infrastructure of an application and its design to identify potential vulnerabilities that can be exploited. High-risk threats to web applications In particular, enterprises need to be aware of the following threats to web applications. The focus is on the wide repertoire of techniques adversaries use to compromise web applications and sites: DoS (Denial of Service): DoS attacks involve hackers overwhelming a web application with multiple requests for information, slowing down the operation of a website or entirely taking it down. A multi-source attack is considered a distributed DoS or DDoS, which routes the malicious traffic through a bigger number of servers. Attackers may also upload dangerous files, which may be downloaded by employees or processed in a corporate environment. Cross-site scripting (XSS): This is a common vulnerability that exploits web application weaknesses to attack users. The attack involves hackers passing data that’s crafted to masquerade legitimate functionality; without proper validation of data, malicious code is transferred to the web browser. In many cases, cyber criminals craft attacks via JavaScript, but attacks may also include Flash, HTML, or another code executed by web browsers. Cross-site scripting enable hackers to steal credentials, hijack sessions, or redirect users to malicious sites. SQL injection: These are random attacks that target applications with weak security to inject malware to extract data or aid virus distribution. These two scenarios are often a result of poor programming. Successful attacks involve hackers modifying the logic of SQL statements against databases. The application, in most cases, builds dynamic query statements, enabling malicious users to work with the data. Consequences can include data corruption, account compromise, or even a complete host takeover. Parameter & buffer manipulation: Websites often use URL parameters to pass information between web pages. Hackers can take advantage of this process and rewrite parameters in malicious ways. They may also manipulate buffers (a small storage allocated for data), andoverload them so that additional data overwrites data in other areas. Hackers may also override data with their own malicious code. Security policy template Security policies are, in effect, a strategy to protect web applications and ensure availability at all times. These generally include steps to identify responsibilities, predict threat vectors, and determine prevention & mitigation methodologies. It is essential to define rules for ensuring high availability of applications and minimizing weaknesses. Access and control mechanisms It is common for web applications to lack sufficient authorization checks for people attempting to access their resources. In a secure environment, there should be both role based and user access controls. Organizations should ensure that users can’t bypass ACLs by navigating directly to a file or page. This can be done by setting ACLs to default grant or deny access to authorized users and roles. The IT team can also utilize vetted frameworks and libraries. Access and control should be kept separate, and custom authorization routines should be avoided, as they make the authentication of all necessary channels more challenging. Delineation of responsibilities Never assume there are predefined responsibilities to access files and data stored by web applications. A lot of testing and experience goes into vetted frameworks, encryption algorithms and libraries, so make sure there is a clear description of responsibilities for every user at every possible step. The more default the set of responsibilities, the more difficult it will become to securing the application. Roles and access control are not just for developers, but for all people involved in using web applications. You need to have some delineation of roles with different levels of access for each user. While every organization’s application development program will be different, responsibilities can be handled in different ways or added in different places, and still be effective. Security resources and tools A well-defined policy template includes the use of encryption algorithm for web applications. Users have to determine the data that is valuable enough for encryption, and identify vulnerabilities through threat modeling. Some resources may have to be sacrificed to secure highly sensitive data. Implementations like a web application firewall will safeguard enterprise applications and websites from any cyber threat, so you can avoid costly downtime and data breach attacks. Enterprises are recommended to look for PCI-certified WAF as it protects against Cross-site scripting, SQL injections, and other threats. Some offerings include custom security rules that let you enforce security policies efficiently while eliminating false positives. New solutions are also using crowdsourcing techniques to protect applications with collective knowledge about the modern threat landscape. Threat information is aggregated using big data analytics. Disaster recovery and emergency mechanisms Disaster recovery solutions are required for immediate response to high-risk situations and mitigation strategies must be deployed to limit exposure from an attack. Disaster recovery should be allowed to bypass security assessments and address the risk before a proper assessment can be carried out. Patch releases, on the other hand, are subjected to appropriate level assessment based on the threats to the application architecture and/or functionality. CIOs are the personnel in charge of disaster recovery initiatives. Emergency mechanisms may include steps to take the application off-the-web or stop functionality release into the live environment if multiple threats increase the risk to unacceptable levels. Emergencies should be addressed in a point/patch release unless other mitigation strategies limit exposure. Credentials after patching may be temporarily stored outside of the webroot until the application infrastructure is tested in updated areas of the application environment. Other measures When web applications feature hard-coded credentials, the user can store credentials in the form of hashes to improve security in case the database or the configuration files get breached. Strict ACLs can also be deployed to protect credentials. Enterprises should also use a whitelist of acceptable input commands. If applications are configured to construct SQL queries, but include vulnerabilities that enable hackers to modify these queries, then it is beneficial to avoid dynamic queries, quote arguments, and special characters. The database inputs should be sanitized in general, and there should be strict rules for input validation. Compliance measures and business benefits When it comes to compliance, users who violate this policy should be subjected to a hearing, which may be concluded with a disciplinary action such as termination of employment, depending on the nature of violation. Everyone accessing web applications should undergo assessment as a requirement of a security policy and adhere to the policy unless exempted in certain circumstances. The infrastructure of all applications should be updated to include the security control process. Any web applications that lack appropriate security controls should be taken down for formal assessment, and should not make their way online until the CIO clears them for security integration. All these measures will result in business benefits, such as no loss of productivity during downtimes, and ensure SLAs are met. An enterprise with highly secured web applications will also attract more clients, as they would be better able to protect sensitive customer information. Organizations following the security policy template would also enjoy technical benefits such as high availability and security of data. Both these factors are likely to improve client-wide and industry wide reputation. Lastly, the policy will bridge the gap between good IT practices and enterprise security compliance. Source

Top operating systems by vulnerabilities reported in 2014 Top applications by vulnerabilities reported in 2014 Most vulnerable operating systems and applications in 2014

What drove IT admins crazy about the Bash vulnerability was that it was difficult to determine—and patch—everything that was making a Bash call. It was everywhere. Apparently, some of that angst applies to the Ghost vulnerability in the GNU C library, known as glibc. At first, experts believed the bug, which was related to gethostbyname function calls, was confined to Linux systems, but it didn’t take long for other exploit vectors such as PHP applications, to surface. Researchers at Veracode this week published their look at Ghost and determined that like Bash, gethostbyname is relatively everywhere. And what’s sure to compound lingering frustration over Ghost is that gethostbyname was long ago deprecated and replaced by getaddrinfo() calls in order to satisfy IPv6 compatibility. “We were surprised by the pervasiveness of calls to these functions, which are older functions which have been deprecated for about 15 years, mainly because of their lack of support for IPv6,” said Veracode cofounder and CTO Chris Wysopal. “So this analysis shows that there’s still a lot of old software out there that’s being used in production applications.” Veracode said that 41 percent of the enterprise applications uploaded to its platform in the past 90 days rely on glibc to make gethostbyname function calls. The company added that 80 percent of those potentially vulnerable applications are critical off-the-shelf or homegrown business apps that access databases and backend systems executing sensitive transactions. Most of those vulnerable applications, Veracode said, were written in C or C++, but many are also Java, PHP and .NET apps. “This implies that the vulnerability may be more widespread than might otherwise be expected,” Wysopal said. “Knowing exactly where these applications reside can help enterprises prioritize their patching efforts in globally-distributed environments.” Ghost affects most Linux systems dating back almost 15 years, in particular glibc 2.2 through 2.17. The vulnerability was patched in May 2013, though the patch was not labeled a security vulnerability and as a result may not have been widely deployed. Since the bug was disclosed, most Linux distributions have released patches, and experts say this is the best mitigation for Ghost. Researchers at Qualys discovered the vulnerability and posted a lengthy advisory that included proof-of-concept exploit code against the Exim SMTP mail transfer agent. In addition to Exim, clockdiff, procmail and pppd were initiallyidentified as vulnerable to Ghost exploits. Since then, researchers at Sucuri also said that PHP applications, including WordPress, were another weak spot. Exploiting Ghost, however, remains a challenge. “Unlike with Heartbleed, which was a protocol-level vulnerability, exploiting this vulnerability requires a specially-crafted payload that has been targeted for a specific application and hardware platform,” Wysopal said. “That means you can’t simply reuse the proof-of-concept exploit developed by Qualys (for the Exim mail server) to attack other applications. As a result, GHOST attacks are more likely to be sophisticated and targeted.” Like other Internet-wide bugs, this one can be exploited to execute code remotely, manipulate files, install malware or turn the compromised machine into a bot to be used in DDoS attacks. “Some researchers believe that the most likely outcome in a real-world scenario would be a segmentation fault, not code execution, but this can also result in a DoS attack,” Wysopal said. The Ghost bug and other major vulnerabilities of the last nine months are a reminder of the frailty of open source security as well as how much insecure legacy code is running inside most enterprises. “The most important conclusion is that our entire digital infrastructure is built on applications and components that were fundamentally not designed for the hostile cyber environment in which we find ourselves today,” said Wysopal, who added that 90 percent of the applications scanned and analyzed by Veracode’s service contain common application security vulnerabilities such as SQL injection. “Rather, they were designed with a primary focus on functionality rather than on secure programming practices.” Source