This article may be in need of reorganization to comply with Wikipedia's layout guidelines. (August 2016) (Learn how and when to remove this template message)
|This article is part of a series on|
|Related security categories|
An always evolving but largely consistent set of common security flaws are seen across different applications, see common flaws
Different techniques will find different subsets of the security vulnerabilities lurking in an application and are most effective at different times in the software lifecycle. They each represent different tradeoffs of time, effort, cost and vulnerabilities found.
Utilizing these techniques appropriately throughout the software development life cycle (SDLC) to maximize security is the role of an application security team.
According to the patterns & practices Improving Web Application Security book, the following are classes of common application security threats / attacks:
|Category||Threats / Attacks|
|Input Validation||Buffer overflow; cross-site scripting; SQL injection; canonicalization|
|Software Tampering||Attacker modifies an existing application's runtime behavior to perform unauthorized actions; exploited via binary patching, code substitution, or code extension|
|Authentication||Network eavesdropping ; Brute force attack; dictionary attacks; cookie replay; credential theft|
|Authorization||Elevation of privilege; disclosure of confidential data; data tampering; luring attacks|
|Configuration management||Unauthorized access to administration interfaces; unauthorized access to configuration stores; retrieval of clear text configuration data; lack of individual accountability; over-privileged process and service accounts|
|Sensitive information||Access sensitive code or data in storage; network eavesdropping; code/data tampering|
|Session management||Session hijacking; session replay; man in the middle|
|Cryptography||Poor key generation or key management; weak or custom encryption|
|Parameter manipulation||Query string manipulation; form field manipulation; cookie manipulation; HTTP header manipulation|
|Exception management||Information disclosure; denial of service|
|Auditing and logging||User denies performing an operation; attacker exploits an application without trace; attacker covers his or her tracks|
The proportion of mobile devices providing open platform functionality is expected to continue to increase in future. The openness of these platforms offers significant opportunities to all parts of the mobile eco-system by delivering the ability for flexible program and service delivery= options that may be installed, removed or refreshed multiple times in line with the user’s needs and requirements. However, with openness comes responsibility and unrestricted access to mobile resources and APIs by applications of unknown or untrusted origin could result in damage to the user, the device, the network or all of these, if not managed by suitable security architectures and network precautions. Application security is provided in some form on most open OS mobile devices (Symbian OS, Microsoft, BREW, etc.). Industry groups have also created recommendations including the GSM Association and Open Mobile Terminal Platform (OMTP).
There are several strategies to enhance mobile application security including
Security testing techniques scour for vulnerabilities or security holes in applications. These vulnerabilities leave applications open to exploitation. Ideally, security testing is implemented throughout the entire software development life cycle (SDLC) so that vulnerabilities may be addressed in a timely and thorough manner. Unfortunately, testing is often conducted as an afterthought at the end of the development cycle.
Vulnerability scanners, and more specifically web application scanners, otherwise known as penetration testing tools (i.e. ethical hacking tools) have been historically used by security organizations within corporations and security consultants to automate the security testing of http request/responses; however, this is not a substitute for the need for actual source code review. Physical code reviews of an application's source code can be accomplished manually or in an automated fashion. Given the common size of individual programs (often 500,000 lines of code or more), the human brain cannot execute a comprehensive data flow analysis needed in order to completely check all circuitous paths of an application program to find vulnerability points. The human brain is suited more for filtering, interrupting and reporting the outputs of automated source code analysis tools available commercially versus trying to trace every possible path through a compiled code base to find the root cause level vulnerabilities.
There are many kinds of automated tools for identifying vulnerabilities in applications. Some require a great deal of security expertise to use and others are designed for fully automated use. The results are dependent on the types of information (source, binary, HTTP traffic, configuration, libraries, connections) provided to the tool, the quality of the analysis, and the scope of vulnerabilities covered. Common technologies used for identifying application vulnerabilities include:
Static Application Security Testing (SAST) is a technology that is frequently used as a Source Code Analysis tool. The method analyzes source code for security vulnerabilities prior to the launch of an application and is used to strengthen code. This method produces fewer false positives but requires access to an application's source code.
Dynamic Application Security Testing (DAST) is a technology, which is able to find visible vulnerabilities by feeding a URL into an automated scanner. This method is highly scalable, easily integrated and quick. DAST's drawbacks lie in the need for expert configuration and the high possibility of false positives and negatives.
Interactive Application Security Testing (IAST) is a solution that assesses applications from within using software instrumentation. This technique allows IAST to combine the strengths of both SAST and DAST methods as well as providing access to code, HTTP traffic, library information, backend connections and configuration information. Some IAST products require the application to be attacked, while others can be used during normal quality assurance testing.
The advances in professional Malware targeted at the Internet customers of online organizations have seen a change in Web application design requirements since 2007. It is generally assumed that a sizable percentage of Internet users will be compromised through malware and that any data coming from their infected host may be tainted. Therefore, application security has begun to manifest more advanced anti-fraud and heuristic detection systems in the back-office, rather than within the client-side or Web server code. As of 2016, runtime application self-protection (RASP) technologies have been developed. RASP is a technology deployed within or alongside the application runtime environment that instruments an application and enables detection and prevention of attacks.
None of the audio/visual content is hosted on this site. All media is embedded from other sites such as GoogleVideo, Wikipedia, YouTube etc. Therefore, this site has no control over the copyright issues of the streaming media.
All issues concerning copyright violations should be aimed at the sites hosting the material. This site does not host any of the streaming media and the owner has not uploaded any of the material to the video hosting servers. Anyone can find the same content on Google Video or YouTube by themselves.
The owner of this site cannot know which documentaries are in public domain, which has been uploaded to e.g. YouTube by the owner and which has been uploaded without permission. The copyright owner must contact the source if he wants his material off the Internet completely.