==A1-Injection

Injection flaws, such as SQL, OS, XXE, and LDAP injection occur when
untrusted data is sent to an interpreter as part of a command or query. The
attackers hostile data can trick the interpreter into executing unintended
commands or accessing data without proper authorization.

==A2-Broken Authentication and Session Management

Application functions related to authentication and session management

are often implemented incorrectly, allowing attackers to compromise passwords,
keys, or session tokens, or to exploit other implementation flaws to assume other
users identities (temporarily or permanently).

==A3-Cross-Site Scripting (XSS)

XSS flaws occur whenever an application includes untrusted data in a new
web page without proper validation or escaping, or updates an existing web page
with user supplied data using a browser API that can create JavaScript. XSS allows
attackers to execute scripts in the victims browser which can hijack user sessions,
deface web sites, or redirect the user to malicious sites.

==A4-Broken Access Control new

Restrictions on what authenticated users are allowed to do are not
properly enforced. Attackers can exploit these flaws to access unauthorized
functionality and/or data, such as access other users' accounts, view sensitive
files, modify other users data, change access rights, etc.

==A5-Security Misconfiguration
 Good security requires having a secure configuration defined and deployed for
the application, frameworks, application server, web server, database server, platform,
etc. Secure settings should be defined, implemented, and maintained, as defaults are
often insecure. Additionally, software should be kept up to date.

==A6-Sensitive Data Exposure

Many web applications and APIs do not properly protect sensitive data, such as
financial, healthcare, and PII. Attackers may steal or modify such weakly protected data
to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves
extra protection such as encryption at rest or in transit, as well as special precautions
when exchanged with the browser.

==A7-Insufficient Attack Protection new

The majority of applications and APIs lack the basic ability to detect, prevent, and
respond to both manual and automated attacks. Attack protection goes far beyond
basic input validation and involves automatically detecting, logging, responding, and
even blocking exploit attempts. Application owners also need to be able to deploy
patches quickly to protect against attacks.

==A8-Cross-Site Request Forgery (CSRF)

A CSRF attack forces a logged-on victims browser to send a forged HTTP request,
including the victims session cookie and any other automatically included
authentication information, to a vulnerable web application. Such an attack allows the
attacker to force a victims browser to generate requests the vulnerable application
thinks are legitimate requests from the victim.

==A9-Using Components with Known Vulnerabilities

Components, such as libraries, frameworks, and other software modules, run

with the same privileges as the application. If a vulnerable component is exploited, such
an attack can facilitate serious data loss or server takeover. Applications and APIs using
components with known vulnerabilities may undermine application defenses and
enable various attacks and impacts.
==A10-Underprotected APIs new

applications often involve rich client applications and APIs, such as JavaScript in
the browser and mobile apps, that connect to an API of some kind (SOAP/XML,
REST/JSON, RPC, GWT, etc.). These APIs are often unprotected and contain numerous
vulnerabilities.

- No cache

client side storage

- No store

no storage

- http only coookie

Clickjacking

X-Frame-Options: Deny and X-Frame-Options: SameOrigin.

Token length

Session Time-out

Cookie configuration:

path - In addition to the domain, the URL path that the cookie is valid for can be
specified. If the domain and path match, then the cookie will be sent in the
request. Just as with the domain attribute, if the path attribute is set too loosely,
then it could leavethe application vulnerable to attacks by other applications on
the
same server.
For example, if the path attribute was set to the web server root
/, then the application cookies will be sent to every application
within the same domain.

HttpOnly Session ID in URL and Page Body

Directory Traversal

Lfi - RFI

cookie's expiration, domain, and flags (such as Secure and HttpOnly

A web service typically offers a WSDL from which you can create client stubs
automatically. Web Services are based on the SOAP protocol. Web API is a newer
Microsoft framework which helps you to build REST based interfaces. The
response can be either JSON or XML, but there is no way to generate clients
automatically because Web Api does not offer a service description like the WSDL
from Web Services. So it depends on your requirements which one of the
techniques you want to use. Perhaps even WCF fits your requirements better, just
look at the MSDN

Web Service:
Web Service:
1) It is a SOAP based service and returns data as XML.

2) It only supports the HTTP protocol.

3) It can only be hosted on IIS.

4) It is not open source, but can be used by any client that understands
XML.

5) It requires a SOAP protocol to receive and send data over the network,
so it is not a light-weight architecture.
Web API:

1) A Web API is a HTTP based service and returns JSON or XML data by
default.
2) It supports the HTTP protocol.

3) It can be hosted within an application or IIS.

4) It is open source and it can be used by any client that understands
JSON or XML.

5) It is light-weight architectured and good for devices which have limited

bandwidth, like mobile devices.
 Plist files
Keychain
Applications home directory
Cache
Logs
Private/var/containers/buldle/application/(application id)
Checks
*Local storage
-sqlite files, plist files, nsuserdefaults, core data, keychain
* Data leakage
- app background in, keyboard cache, paste board
*Runtime analysis
- dumping class information, runtime code injection using
 cycript, method swizzling, bypassing jailbreak, run time
analysis using gdb and snoop it

Plist files /Library/Preference

Keychain /private/var/Keychains/keychain-2.db
Applications home directory
Cache Library/Caches/Snapshots
Library/Keyboard/en_GB-dynamic-text.dat
Logs

Plist files

however, the applications may use Plist files to store clear text
usernames, passwords and session related information. So

s. Also, do not take authentication & authorization decisions

based on the information stored in Plist files.
On a non JailBroken iPhone, Plist files can be viewed &
modified using tools like iExplorer and iBackupBot.

/Library/Preference
Keychain

/private/var/Keychains/keychain-2.db

Keychain is an encrypted container (128 bit AES

algorithm) and a centralized SQLite database that holds
identities & passwords for multiple applications and
network services, with restricted access rights.

SQLite storage
Unencrypted sensitive information stored in a SQLite file
can be stolen easily by gaining physical access to the
device or from the device backup. I

- app background in, keyboard cache, paste board

Cache
Cookies.binarycookies
. Most of the iOS applications do not want to prompt the
user for login every time. So, they create persistent
cookies and store them in cookies.binarycookies file on
the applications home directory. During the penetration
test, investigate the cookies.binarycookies file for
sensitive information, and to find session management
issues. Cookies.binarycookies is a binary file and the
content is not in readable format. Therefore, I wrote a
python script BinaryCookieReader.py that can read the
cookie file and display the content on the screen.

Keyboard Cache
In an effort to learn how users type, iOS devices utilize a
feature called Auto Correction to populate a local
keyboard cache on the device. The keyboard cache is
designed to autocomplete the predictive common words.
The problem with this feature is, it records everything
that a user types in text fields. The cache keeps a list of
approximately 600 words. The keyboard cache is located
at Library/Keyboard/en_GB-dynamic-text.dat file. To
view the Keyboard cache, copy the en_GB-dynamic-
text.dat file to a computer over SSH and open the file
using a Hex Editor. Below is the screenshot of a
keyboard cache Hex view.
Library/Keyboard/en_GB-dynamic-text.dat
Snapshot Storage
Pressing the iPhone home button shrinks the iOS
application and moves it to the background with a nice
effect. To create that shrinking effect, iOS takes a
screenshot of the application and stores it in the
Library/Caches/Snapshots folder in the respective
applications home directory. This might result in storing
the users sensitive information on the device without
users knowledge. Snapshots stored on the iPhone will
automatically clear after the device is rebooted.
Library/Caches/Snapshots

app background in
home button press

Error Logs
iPhone configuration utility to view logs

https://github.com/iSECPartners/ios-ssl-kill-switch
dpkg -i <package>.deb

killall -HUP SpringBoard

dpkg -r com.isecpartners.nabla.sslkillswitch

The tool was tested on iOS7 running on an

iPhone 5S.

https://github.com/nabla-c0d3/ssl-kill-switch2

Once loaded into an iOS or OS X App, SSL Kill

Switch 2

ssl-killer