Вы находитесь на странице: 1из 8

Running head: WEB APPLICATION AND MOBILE CODE SECURITY

Web Application and Mobile Code Security


Mitesh Patel
Herzing University
Information Security and Privacy
David Ostrowski
April 10, 2016

WEB APPLICATION AND MOBILE CODE SECURITY

Web Application and Mobile Code Security


Mobile application security is one of the fastest growing problem areas for developers
and ultimately executives today. Other layers of security, such as perimeter, network, and even
data center, have established solutions in place to protect enterprises. However there are still
living in the infancy of mobile application security. Right now, the coding lifecycle is still a bit
Wild West. On the other hand, many mobile application developers institute best practices to
produce more secure applications. The Gartner analyst firm predicted that through 2015, 75
percent of mobile applications would fail basic tests related to security and enterprise policy
(Prince, 2015).
Security and privacy issues in mobile code
1. Excessive Permissions: Most of the mobile applications residing on the mobile devices have
more access permissions and privileges than are required on the device. These permissions might
include access to users contact list and the ability to update the contact list without notifying
user, receiving & sending SMS messages, location (recording users GPS coordinates), and
access to other device hardware components such as the camera, microphone etc. Application
permissions should be limited to only the necessary components required for the functionality of
the application. Moreover, to resist the urge to collect permissions that might be used at a future
date (Prince, 2015).
2. TLS (Transport layer security) fail: Mobile devices operate extensively on open Wi-Fi networks
where anyone in range can listen in on traffic intended for other users. Most developers
understand the importance of transport layer security for this reason. However, implementing
this properly is more challenging for mobile developers than for those who develop web
applications used by standard browsers. Among developers who do try to implement transport
layer security, many will code their application to ignore certificate verification to work around

WEB APPLICATION AND MOBILE CODE SECURITY

the complications in setting up a proper test environment. Certificate verification allows the
mobile application to ensure it is communicating with the intended web services and not a
malicious proxy. Turning off this verification allows an attacker on sensitive traffic, especially if
that user is operating in a malicious or compromised network.
3. Protect the Key: Practices such as hard-coding a key directly into a mobile application can be
problematic that shows Security Week. It must be assumed that keys stored in the mobile app
and/or on the mobile device will be compromised due to the possibility of rooting or jail
breaking a device. If the developer stores the key on the device it is an incomplete and insecure
solution. If the developer prompts for credentials to generate the key whenever it is needed, there
will be a degraded user experience. As a solution, developers should look to Authorization 2.0 to
eliminate the need to store keys on the device. The advantage of this approach, is that if an
outsider gets access to the device or records the token via a man-in-the-middle attack, they only
receive a restrictive token that is usable for certain use cases, such as viewing specific content.
4. Protecting Privacy: Developers also sometimes make the mistake of failing to encrypt
application project resources, settings and preference files like .list and .xml files. These files can
contain sensitive information such as the last logged in user, address, usernames, session tokens,
device UDID, etc. And Moreover, This is not only limited to just project resource or settings
files. Even the photos, videos taken by the application, user locations (GPS) and other user
sensitive information stored by the applications locally on the device in various image, media
and SQLite database files are also often found to be unencrypted (Prince, 2015).
Common threats and vulnerabilities for Web browsers
1. Injection flaws: Injection flaws result from a classic failure to filter untrusted input. It can happen
when you pass unfiltered data to the SQL server (SQL injection), to the browser to the LDAP
server (LDAP injection), or anywhere else. The problem here is that the attacker can inject
commands to these entities, resulting in loss of data and hijacking clients browsers. Anything

WEB APPLICATION AND MOBILE CODE SECURITY

that your application receives from untrusted sources must be filtered, preferably according to a
whitelist. One should almost never use a blacklist, as getting that right is very hard and usually
easy to bypass (Kalman, n.d.).
2. Insecure Direct Object References: This is a classic case of trusting user input and paying the
price in a resulting security vulnerability. A direct object reference means that an internal object
such as a file or database key is exposed to the user. The problem with this is that the attacker can
provide this reference and, if authorization is either not enforced (or is broken), the attacker can
access or do things that they should be precluded from. For example, the code has a
download.php module that reads and lets the user download files, using a CGI parameter to
specify the file name. Either by mistake or due to laziness, the developer omitted authorization
from the code.
3. Sensitive data exposure: This web security vulnerability is about crypto and resource protection.
Sensitive data should be encrypted at all times, including in transit and at rest. Credit card
information and user passwords should never travel or be stored unencrypted, and passwords
should always be hashed. Obviously the crypto/hashing algorithm must not be a weak one. And
while it goes without saying that session IDs and sensitive data should not be traveling in the
URLs and sensitive cookies should have the secure flag on, this is very important and cannot be
over-emphasized.
4. Missing function level access control: This is simply an authorization failure. It means that when
a function is called on the server, proper authorization was not performed. A lot of times,
developers rely on the fact that the server side generated the UI and they think that the
functionality that is not supplied by the server cannot be accessed by the client. It is not as simple
as that, as an attacker can always forge requests to the hidden functionality and will not be
deterred by the fact that the UI doesnt make this functionality easily accessible. Nothing keeps

WEB APPLICATION AND MOBILE CODE SECURITY

an attacker from discovering this functionality and misusing it if authorization is missing


(Kalman, n.d.).
Web server threats and vulnerabilities
1. Brute Force Attack: In a brute force attack, the intruder attempts to gain access to a server by
guessing a user password (usually the root administrator) through the SSH server, Mail server, or
other service running on your system. The attacker will normally use software that will check
every possible combination to find the one that works. Brute force detection software will alert
you when multiple failed attempts to gain access are in progress and disable access from the
offending IP address (Hampton, 2011).
2. DoS: DoS stands for Denial of Service, and is a technique attackers will use to effectively shut
off access to your site. They accomplish this by increasing traffic on your site so much that the
victims server becomes unresponsive. While some DoS attacks come from single attackers,
others are coordinated and are called Distributed Denial of Service (DDoS) attacks. Often times,
the users of computers executing a DDoS do not even know their computers are being used as
agents.
3. Malware: Malware can take many forms, but as the name implies, it is malicious software. It can
take the form of viruses, bots, spyware, worms, Trojans, rootkits, and any other software
intended to cause harm. In most cases, malware is installed without the users direct consent. It
may attack the users computer and/or attack other computers through the users own system.
Having proper firewall and security software protection can usually prevent malware from
spreading.
4. Unpatched Software: Most threats to a server can be prevented simply by having up-to-date,
properly-patched software. All server operating system vendors and distributions publish security
updates. By installing them on your system in a timely manner, you prevent attackers from using
your servers own vulnerabilities against it (Hampton, 2011).
Security controls needed to mitigate the web risks

WEB APPLICATION AND MOBILE CODE SECURITY

Security information and event management products can help make sense of the
overwhelming amount of threat data, and provide information to mitigate the risk of attacks, they
are only part of an organizations security controls. It is also essential that those controls are
regularly checked and tested, to ensure that the network has no weaknesses in its defensive
amour that could be exploited. In addition to penetration testing and vulnerability scanning to
identify potential issues, there are a few basic, but essential, steps that all organizations should
repeat regularly to minimize the risks of giving an attacker an easy entry point.
1. Firewall configurations: It is important for firewall configurations to be regularly reviewed and
independently audited to ensure that only the absolutely necessary configuration is active. When
performing external penetration testing, we commonly see remote management services exposed
to the public internet rather than being correctly filtered to only permit access from trusted
networks such as the LAN or VPN (Green, 2015).
2. Network segregation: Along with checking the firewall configuration, it is important to check
that segregation is working effectively across all network egress and ingress points. Businesses
should check for network anomalies arising from the segregation between servers and clients.
3. Web applications: Weaknesses and vulnerabilities in web applications are quickly becoming one
of the main attack vectors through which organizations are compromised. The main threats
usually found within clients applications are SQL Injection, Cross Site Scripting and Parameter
Tampering attacks. Along with regular web application penetration testing, all applications
should be securely coded using an appropriate methodology, such as the Open Web Application
Security Project (OWASP) secure coding guidelines. Whilst performing a review of applications,
checks could also include ensuring that no dynamic queries are used in application code, input
validation and sanitization is correctly implemented and that authority checks are present for all
user-controllable input.

WEB APPLICATION AND MOBILE CODE SECURITY

4. Username enumeration and strong passwords: Some of the common findings on the Internal
Penetration Tests we perform include file shares without appropriate permissions. The ability to
enumerate usernames due to incorrectly configured Windows domain services. These flaws,
often lead to privileges being gained on the network. Organizations need to ensure that all users
set strong passwords that go beyond simply meeting the current password complexity criteria.
Organizations must encourage users to take the time to set a suitable complex password, then test
them regularly to ensure that they are appropriately strong (Green, 2015).
Conclusion
Web application vulnerabilities have been a thorn in the side of IT security for years.
They are not new and neither are the fixes for them, but until the security of Web apps is
prioritized, attackers seeking to commit theft, fraud and cyberespionage will all continue to take
advantage of these flaws.
References
Green, C. (2015, May 28). Six network security checks to mitigate the risk of data security
breaches | Information Age. Retrieved April 10, 2016, from http://www.informationage.com/technology/security/123459554/six-network-security-checks-mitigate-risk-datasecurity-breaches
Hampton, T. (2011, March 4). 9 Server Security Threats You Should Definitely Know. Retrieved
April 10, 2016, from http://www.webmasterview.com/2011/03/server-security-threats/
Kalman, G. (n.d.). 10 Most Common Web Security Vulnerabilities. Retrieved April 09, 2016,
from https://www.toptal.com/security/10-most-common-web-security-vulnerabilities
Prince, B. (2015, March 18). Common Mobile Application Security, Privacy Challenges |
SecurityWeek.Com. Retrieved April 08, 2016, from
http://www.securityweek.com/common-mobile-application-security-privacy-challenges

WEB APPLICATION AND MOBILE CODE SECURITY

Вам также может понравиться