YES24 보안사고  보도:

http://www.yonhapnews.co.kr/bulletin/2016/04/04/0200000000AKR20160404181900005.HTML



인터파크 보안사고 보도

http://www.itworld.co.kr/news/100473

블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

files.zip

진단보고서양식_v1.docx


블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

android_securecoding_en.pdf


블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹


블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

https://www.owasp.org/index.php/OWASP_Internet_of_Things_Top_Ten_Project#tab=OWASP_Internet_of_Things_Top_10_for_2014


Manufacturer IoT Security Guidance

(DRAFT)


The goal of this section is help manufacturers build more secure products in the Internet of Things space. The guidance below is at a basic level, giving builders of products a basic set of guidelines to consider from their perspective. This is not a comprehensive list of considerations, and should not be treated as such, but ensuring that these fundamentals are covered will greatly improve the security of any IoT product.

CategoryIoT Security Consideration
I1: Insecure Web Interface
  • Ensure that any web interface in the product disallows weak passwords
  • Ensure that any web interface in the product has an account lockout mechanism
  • Ensure that any web interface in the product has been tested for XSS, SQLi and CSRF vulnerabilities
  • Ensure that any web interface has the ability to use HTTPS to protect transmitted information
  • Include web application firewalls to protect any web interfaces
  • Ensure that any web interface allows the owner to change the default username and password
I2: Insufficient Authentication/Authorization
  • Ensure that any access requiring authentication requires strong passwords
  • Ensure that user roles can be properly segregated in multi-user environments
  • Implement two-factor authentication where possible
  • Ensure password recovery mechanisms are secure
  • Ensure that users have the option to require strong passwords
  • Ensure that users have the option to force password expiration after a specific period
  • Ensure that users have the option to change the default username and password
I3: Insecure Network Services
  • Ensure all devices operate with a minimal number of network ports active
  • Ensure all devices do not make network ports and/or services available to the internet via UPnP for example
  • Review all required network services for vulnerabilities such as buffer overflows or denial of service
I4: Lack of Transport Encryption
  • Ensure all communication between system components is encrypted as well as encrypting traffic between the system or device and the internet
  • Use recommended and accepted encryption practices and avoid proprietary protocols
  • Ensure SSL/TLS implementations are up to date and properly configured
  • Consider making a firewall option available for the product
I5: Privacy Concerns
  • Ensure only the minimal amount of personal information is collected from consumers
  • Ensure all collected personal data is properly protected using encryption at rest and in transit
  • Ensure only authorized individuals have access to collected personal information
  • Ensure only less sensitive data is collected
  • Ensuring data is de-identified or anonymized
  • Ensuring a data retention policy is in place
  • Ensuring end-users are given a choice for data collected beyond what is needed for proper operation of the device
I6: Insecure Cloud Interface
  • Ensure all cloud interfaces are reviewed for security vulnerabilities (e.g. API interfaces and cloud-based web interfaces)
  • Ensure that any cloud-based web interface disallows weak passwords
  • Ensure that any cloud-based web interface has an account lockout mechanism
  • Implement two-factor authentication for cloud-based web interfaces
  • Ensure that all cloud interfaces use transport encryption
  • Ensure that any cloud-based web interface has been tested for XSS, SQLi and CSRF vulnerabilities
  • Ensure that users have the option to require strong passwords
  • Ensure that users have the option to force password expiration after a specific period
  • Ensure that users have the option to change the default username and password
I7: Insecure Mobile Interface
  • Ensure that any mobile application disallows weak passwords
  • Ensure that any mobile application has an account lockout mechanism
  • Implement two-factor authentication for mobile applications (e.g Apple's Touch ID)
  • Ensure that any mobile application uses transport encryption
  • Ensure that users have the option to require strong passwords
  • Ensure that users have the option to force password expiration after a specific period
  • Ensure that users have the option to change the default username and password
I8: Insufficient Security Configurability
  • Ensure password security options are made available (e.g. Enabling 20 character passwords or enabling two-factor authentication)
  • Ensure encryption options are made available (e.g. Enabling AES-256 where AES-128 is the default setting)
  • Ensure secure logging is available for security events
  • Ensure alerts and notifications are available to the user for security events
I9: Insecure Software/Firmware
  • Ensure all system devices have update capability and can be updated quickly when vulnerabilities are discovered
  • Ensure update files are encrypted and that the files are also transmitted using encryption
  • Ensure that update files are signed and then validated by the device before installing
  • Ensure update servers are secure
  • Ensure the product has the ability to implement scheduled updates
I10: Poor Physical Security
  • Ensure the device is produced with a minimal number of physical external ports (e.g. USB ports)
  • Ensure the firmware of Operating System can not be accessed via unintended methods such as through an unnecessary USB port
  • Ensure the product is tamper resistant
  • Ensure the product has the ability to limit administrative capabilities in some fashion, possibly by only connecting locally for admin functions
  • Ensure the product has the ability to disable external ports such as USB

General Recommendations

Consider the following recommendation for all Internet of Things products:

  • Avoid the potential for persistent vulnerabilities in devices that have no update capability by ensuring that all devices and systems are built with the ability to be updated when vulnerabilities are discovered
  • Rebranded devices used as part of a system should be properly configured so that unnecessary or unintended services do not remain active after the rebranding

[ NOTE: Given the fact that each deployment and every environment is different, it is important to weigh the pros and cons of implementing the advice above before taking each step. ]


Developer IoT Security Guidance

(DRAFT)

The goal of this section is help developers build more secure applications in the Internet of Things space. The guidance below is at a basic level, giving developers of applications a basic set of guidelines to consider from their perspective. This is not a comprehensive list of considerations, and should not be treated as such, but ensuring that these fundamentals are covered will greatly improve the security of any IoT product. Strongly consider using a Secure IoT Framework in order to proactively address many of the concerns listed below.

CategoryIoT Security ConsiderationRecommendations
I1: Insecure Web Interface
  • Ensure that any web interface coding is written to prevent the use of weak passwords
  • Ensure that any web interface coding is written to include an account lockout mechanism
  • Ensure that any web interface coding has been tested for XSS, SQLi and CSRF vulnerabilities
  • Ensure that any web interface has the ability to use HTTPS to protect transmitted information
  • Ensure that any web interface coding is written to allow the owner to change the username and password
  • Consider the use of web application firewalls to protect any web interfaces

When building a web interface consider implementing lessons learned from web application security. Employ a framework that utilizes security controls to ensure that vulnerabilities are mitigated in code. Be sure to plan for eventual upgrades or security fixes to the framework as well. If you use optional plugins to the framework be sure to review them for security.

Deploy and protect the web interface in the same way you would any web application. Utilize encrypted transport protocols if possible, being sure to validate certificates. Limit access in whatever ways possible. Assume users will not change configuration so deploy in a secure manner with strong credentials already in place.

I2: Insufficient Authentication/Authorization
  • Ensure that applications are written to require strong passwords where authentication is needed
  • Ensure the application takes into account multi-user environments and includes functionality for role separation
  • Implement two-factor authentication where possible
  • Ensure password recovery mechanisms are written to function in a secure manner
  • Ensure that applications are written to include the option to require strong passwords
  • Ensure that applications are written to include the option to force password expiration after a specific period
  • Ensure that applications are written to include the option to change the default username and password

Refer to the OWASP Authentication Cheat Sheet

I3: Insecure Network Services
  • Ensure applications that use network services don't respond poorly to buffer overflow, fuzzing or denial of service attacks
  • Ensure applications test ports are taken out of service before going to production

Try to utilize tested, proven, networking stacks and interfaces that handle exceptions gracefully. Be sure that any test or maintenance interfaces are disabled or properly protected. Avoid exposing unauthenticated protocols (such as TFTP) or unencrypted channels (such as telnet) if possible. Consider the attack surface that device network services present. Turn off unnecessary services and deploy measures to protect required services, detect malicious activity, and react to an attack with measures such as lock-outs or temporary firewall rules.

I4: Lack of Transport Encryption
  • Ensure all applications are written to make use of encrypted communication between devices and between devices and the internet
  • Use recommended and accepted encryption practices and avoid proprietary protocols
  • Consider making a firewall option available for the application

Utilize encrypted protocols wherever possible to protect all data in transit. Where protocol encryption is not possible consider encrypting data before transfer.

I5: Privacy Concerns
  • Ensure only the minimal amount of personal information is collected from consumers
  • Ensure all collected personal data is properly protected using encryption at rest and in transit
  • Ensuring data is de-identified or anonymized
  • Ensuring end-users are given a choice for data collected beyond what is needed for proper operation of the device

Data can present unintended privacy concerns when aggregated. As a rule collect the minimal amount of data possible. Consult with data scientists, legal and compliance teams to determine risk of data collection and storage. Consider implications of consent and the fact that IoT devices may not present an interface for collecting consent and may passively collect data about people other than owners and operators. IoT may collect information about individuals who cannot provide consent (such as minors) and data collection should be modified accordingly.

I6: Insecure Cloud Interface
  • Ensure all cloud interfaces are reviewed for security vulnerabilities (e.g. API interfaces and cloud-based web interfaces)
  • Ensure that any cloud-based web interface coding is written to disallows weak passwords
  • Ensure that any cloud-based web interface coding is written to include an account lockout mechanism
  • Implement two-factor authentication for cloud-based web interfaces
  • Ensure that any cloud interface coding has been tested for XSS, SQLi and CSRF vulnerabilities
  • Ensure that all cloud interfaces use transport encryption
  • Ensure that cloud interfaces are written to include the option to require strong passwords
  • Ensure that cloud interfaces are written to include the option to force password expiration after a specific period
  • Ensure that cloud interfaces are written to include the option to change the default username and password

Cloud security presents unique security considerations, as well as countermeasures. Be sure to consult your cloud provider about options for security mechanisms. Consult the OWASP Cloud Top 10 Security Risks documents.

I7: Insecure Mobile Interface
  • Ensure that any mobile application coding is written to disallows weak passwords
  • Ensure that any mobile application coding is written to include an account lockout mechanism
  • Implement two-factor authentication for mobile applications (e.g Apple's Touch ID)
  • Ensure that any mobile application uses transport encryption
  • Ensure that mobile interfaces are written to include the option to require strong passwords
  • Ensure that mobile interfaces are written to include the option to force password expiration after a specific period
  • Ensure that mobile interfaces are written to include the option to change the default username and password
  • Ensure that mobile interfaces only collect the minimum amount of personal information needed

Mobile interfaces to IoT ecosystems require targeted security. Consult the OWASP Mobile Project for further guidance.

I8: Insufficient Security Configurability
  • Ensure applications are written to include password security options (e.g. Enabling 20 character passwords or enabling two-factor authentication)
  • Ensure applications are written to include encryption options (e.g. Enabling AES-256 where AES-128 is the default setting)
  • Ensure all applications are written to produce logs for security events
  • Ensure all applications are written to produce alerts and notifications to the user for security events

Security can be a value proposition. Design should take into consideration a sliding scale of security requirements. Architect projects with secure defaults and allow consumers to select options to be enabled or disabled. IoT design should be forward compatible with respect to security - as cipher suites increase and new security technologies become widely available IoT design should be able to adopt these new technologies.

Remember the security lifecycle of protect, detect, and react. Design systems to allow for the detection of malicious activity as well as self defending capabilities and a reaction plan should a compromise be detected. Design all stages of the lifecycle to be evolutionary so improvements can be added to a system or device future releases, updates, or patches.

I9: Insecure Software/Firmware
  • Ensure all applications are written to include update capability and can be updated quickly when vulnerabilities are discovered
  • Ensure all applications are written to process encrypted update files and that the files are transmitted using encryption
  • Ensure all applications are written to process signed files and then validate that file before installation

Many IoT deployments are either brownfield (i.e. applied over existing infrastructure) and/or have an extremely long deployment cycle. To maintain the security of devices over time it is critical to plan for patches and updates.

Confidentiality, Integrity, and Availability (CIA) are primary concerns when providing binaries and updates to edge devices. Encrypt updates before distribution, providing decryption keys along with download instructions to authorized devices. Updates should have cryptographic signatures using public key cryptography that can be verified by devices. A cryptographic signature allows for distribution of updates over untrusted channels, such as Content Delivery Network (CDN), peer-to-peer, or machine to machine (M2M).

Devices should always validate cryptographic certificates and discard updates that are not properly delivered or signed. If unencrypted updates are utilized be sure that a cryptographic hash of the update is provided over an encrypted channel so the device can detect tampering.

Provide a mechanism for issuing, updating and revoking cryptographic keys as well. Key management and lifecycle should be taken into consideration prior to deployment. This includes the SSL trust store, or root trust, on a device, which may have to be modified over the lifespan of the device.

I10: Poor Physical Security
  • Ensure applications are written to utilize a minimal number of physical external ports (e.g. USB ports) on the device
  • Ensure all applications can not be accessed via unintended methods such as through an unnecessary USB port
  • Ensure all applications are written to allow for disabling of unused physical ports such as USB
  • Consider writing applications to limit administrative capabilities to a local interface only

Plan on having IoT edge devices fall into malicious hands. Utilize whatever physical security protections are available. Disable any testing or debugging interfaces, utilize Hardware Security Modules (HSM's), cryptographic co-processors, and Trusted Platform Modules (TPM's) wherever possible.

Consider the implications of a compromised device. Do not share credentials, application or cryptographic keys across multiple devices to limit the scope of damage due to a physical compromise.

Plan for the transfer of ownership of devices and ensure that data is not transferable along with the ownership.

General Recommendations

Consider the following recommendations for all user interfaces (local device, cloud-based and mobile):

  • Avoid potential Account Harvesting issues by:
    • Ensuring valid user accounts can't be identified by interface error messages
    • Ensuring strong passwords are required by users
    • Implementing account lockout after 3 - 5 failed login attempts

[ NOTE: Given the fact that each deployment and every environment is different, it is important to weigh the pros and cons of implementing the advice above before taking each step. ]

Consumer IoT Security Guidance

(DRAFT)

The goal of this section is help consumers purchase secure products in the Internet of Things space. The guidance below is at a basic level, giving consumers a basic set of guidelines to consider from their perspective. This is not a comprehensive list of considerations, and should not be treated as such, but ensuring that these fundamentals are covered will greatly aid the consumer in purchasing a secure IoT product.

CategoryIoT Security Consideration
I1: Insecure Web Interface
  • If your system has the option to use HTTPS, ensure it is enabled
  • If your system has a two factor authentication option, ensure that it is enabled
  • If your system has web application firewall option, ensure that it is enabled
  • If your system has a local or cloud-based web application, ensure that you change the default password to a strong one and if possible change the default username as well
  • If the system has account lockout functionality, ensure that it is enabled
  • Consider employing network segmentation technologies such as firewalls to isolate IoT systems from critical IT systems
I2: Insufficient Authentication/Authorization
  • If your system has a local or cloud-based web application, ensure that you change the default password to a strong one and if possible change the default username as well
  • If the system has account lockout functionality, ensure that it is enabled
  • If the system has the option to require strong passwords, ensure that is enabled
  • If the system has the option to require new passwords after 90 days for example, ensure that is enabled
  • If your system has a two factor authentication option, ensure that it is enabled
  • If your system has the option to set user privileges, consider setting user privileges to the minimal needed for operation
  • Consider employing network segmentation technologies such as firewalls to isolate IoT systems from critical IT systems
I3: Insecure Network Services
  • If your system has a firewall option available, enable it and ensure that it can only be accessed from your client systems
  • Consider employing network segmentation technologies such as firewalls to isolate IoT systems from critical IT systems
I4: Lack of Transport Encryption
  • If your system has the option to use HTTPS, ensure it is enabled
I5: Privacy Concerns
  • Do not enter sensitive information into the system that is not absolutely required, e.g. address, DOB, CC, etc.
  • Deny data collection if it appears to be beyond what is needed for proper operation of the device (If provided the choice)
I6: Insecure Cloud Interface
  • If your system has the option to use HTTPS, ensure it is enabled
  • If your system has a two factor authentication option, ensure that it is enabled
  • If your system has web application firewall option, ensure that it is enabled
  • If your system has a local or cloud-based web application, ensure that you change the default password to a strong one and if possible change the default username as well
  • If the system has account lockout functionality, ensure that it is enabled
  • If the system has the option to require strong passwords, ensure that is enabled
  • If the system has the option to require new passwords after 90 days for example, ensure that is enabled
I7: Insecure Mobile Interface
  • If the mobile application has the option to require a PIN or password, consider using it for extra security (on client and server)
  • If the mobile application has the option to use two factory authentication such as Apple's Touch ID, ensure it is enabled
  • If the system has account lockout functionality, ensure that it is enabled
  • If the system has the option to require strong passwords, ensure that is enabled
  • If the system has the option to require new passwords after 90 days for example, ensure that is enabled
  • Do not enter sensitive information into the mobile application that is not absolutely required, e.g. address, DOB, CC, etc.
I8: Insufficient Security Configurability
  • If your system has the option, enable any logging functionality for security-related events
  • If your system has the option, enable any alert and notification functionality for security-related events
  • If your system has security options for passwords, ensure they are enabled for strong passwords
  • If your system has security options for encryption, ensure they are set for an accepted standard such as AES-256
I9: Insecure Software/Firmware
  • If your system has the option to verify updates, ensure it is enabled
  • If your system has the option to download updates securely, ensure it is enabled
  • If your system has the ability to schedule updates on a regular cadence, consider enabling it
I10: Poor Physical Security
  • If your system has the ability to limit administrative capabilities possible by connecting locally, consider enabling that feature
  • Disable any unused physical ports through the administrative interface

General Recommendations

If you are looking to purchase a device or system, consider the following recommendations:

  • Include security in feature considerations when evaluating a product
  • Place Internet of Things devices on a separate network if possible using a firewall

[ NOTE: Given the fact that each deployment and every environment is different, it is important to weigh the pros and cons of implementing the advice above before taking each step. ]

블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

https://msdn.microsoft.com/en-us/library/ff648636.aspx

블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

Threat Risk Modeling


블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

안드로이드 시큐어코딩 실습환경 설정


AppUSE VM이미지 다운로드 링크: 

https://drive.google.com/uc?export=download&id=0B427_IFDm_f7VFdic1lHLVV0bVk



AppUse  사용자 가이드 다운로드:

https://appsec-labs.com/wp-content/uploads/2014/10/appuse_userguide_v2-2.pdf


Anti-Decompile 도구 APK Protect 다운로드:

https://sourceforge.net/projects/apkprotect/




블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

https://www.owasp.org/index.php/Application_Threat_Modeling




원문---------------------------------------------------



Application Threat Modeling


Introduction

Threat modeling is an approach for analyzing the security of an application. 

It is a structured approach that enables you to identify, quantify, and address the security 

risks associated with an application. Threat modeling is not an approach to reviewing code, 

but it does complement the security code review process. 

The inclusion of threat modeling in the SDLC can help to ensure that applications are being 

developed with security built-in from the very beginning. 

This, combined with the documentation produced as part of the threat modeling process, 

can give the reviewer a greater understanding of the system. This allows the reviewer to see 

where the entry points to the application are and the associated threats with each entry point. 

The concept of threat modeling is not new but there has been a clear mindset change in 

recent years. Modern threat modeling looks at a system from a potential attacker's perspective, 

as opposed to a defender's viewpoint. 

Microsoft have been strong advocates of the process over the past number of years. 

They have made threat modeling a core component of their SDLC, which they claim to be 

one of the reasons for the increased security of their products in recent years.

When source code analysis is performed outside the SDLC, such as on existing applications, 

the results of the threat modeling help in reducing the complexity of the source code analysis 

by promoting an in-depth first approach vs. breadth first approach. 

Instead of reviewing all source code with equal focus, you can prioritize the security code 

review of components whose threat modeling has ranked with high risk threats.

The threat modeling process can be decomposed into 3 high level steps:


Step 1: Decompose the Application. The first step in the threat modeling process is concerned 

with gaining an understanding of the application and how it interacts with external entities. 

This involves creating use-cases to understand how the application is used, identifying entry 

points to see where a potential attacker could interact with the application, 

identifying assets i.e. items/areas that the attacker would be interested in, 

and identifying trust levels which represent the access rights that the application will grant to 

external entities. This information is documented in the Threat Model document and it is also 

used to produce data flow diagrams (DFDs) for the application. The DFDs show the different 

paths through the system, highlighting the privilege boundaries.


Step 2: Determine and rank threats. Critical to the identification of threats is using a threat 

categorization methodology. A threat categorization such as STRIDE can be used, or the Application 

Security Frame (ASF) that defines threat categories such as Auditing & Logging, Authentication, 

Authorization, Configuration Management, Data Protection in Storage and Transit, Data Validation, 

Exception Management. 

The goal of the threat categorization is to help identify threats both from the attacker (STRIDE) and

the defensive perspective (ASF). DFDs produced in step 1 help to identify the potential threat targets

from the attacker's perspective, such as data sources, processes, data flows, and interactions with users. 

These threats can be identified further as the roots for threat trees; there is one tree for each threat goal. 

From the defensive perspective, ASF categorization helps to identify the threats as weaknesses of security 

controls for such threats. Common threat-lists with examples can help in the identification of such threats. 

Use and abuse cases can illustrate how existing protective measures could be bypassed, or where a 

lack of such protection exists. The determination of the security risk for each threat can be determined using 

a value-based risk model such as DREAD or a less subjective qualitative risk model based upon general 

risk factors (e.g. likelihood and impact).


Step 3: Determine countermeasures and mitigation. A lack of protection against a threat might indicate a 

vulnerability whose risk exposure could be mitigated with the implementation of a countermeasure. 

Such countermeasures can be identified using threat-countermeasure mapping lists. Once a risk ranking 

is assigned to the threats, it is possible to sort threats from the highest to the lowest risk, and prioritize 

the mitigation effort, such as by responding to such threats by applying the identified countermeasures. 

The risk mitigation strategy might involve evaluating these threats from the business impact that they pose 

and reducing the risk. Other options might include taking the risk, assuming the business impact is 

acceptable because of compensating controls, informing the user of the threat, removing the risk posed 

by the threat completely, or the least preferable option, that is, to do nothing.

Each of the above steps are documented as they are carried out. The resulting document is the threat 

model for the application. This guide will use an example to help explain the concepts behind threat modeling. 

The same example will be used throughout each of the 3 steps as a learning aid. The example that will be

used is a college library website. At the end of the guide we will have produced the threat model for

the college library website. Each of the steps in the threat modeling process are described in detail below.

Decompose the Application

The goal of this step is to gain an understanding of the application and how it interacts with external entities. 

This goal is achieved by information gathering and documentation. The information gathering process is carried 

out using a clearly defined structure, which ensures the correct information is collected. This structure also 

defines how the information should be documented to produce the Threat Model.

Threat Model Information

The first item in the threat model is the information relating to the threat model. This must include the the following:

Application Name - The name of the application.

Application Version - The version of the application.

Description - A high level description of the application.

Document Owner - The owner of the threat modeling document.

Participants - The participants involved in the threat modeling process for this application.

Reviewer - The reviewer(s) of the threat model.

Example:

Threat Model Information

Application Version:

1.0

Description:

The college library website is the first implementation of a website to provide librarians and library patrons (students and college staff) with online services.

As this is the first implementation of the website, the functionality will be limited. There will be three users of the application: 
1. Students
2. Staff
3. Librarians

Staff and students will be able to log in and search for books, and staff members can request books. Librarians will be able to log in, add books, add users, and search for books.

Document Owner:

David Lowry

Participants:

David Rook

Reviewer:

Eoin Keary


External Dependencies

External dependencies are items external to the code of the application that may pose a threat to the application. These items are typically still within the control of the organization, but possibly not within the control of the development team. The first area to look at when investigating external dependencies is how the application will be deployed in a production environment, and what are the requirements surrounding this. This involves looking at how the application is or is not intended to be run. For example if the application is expected to be run on a server that has been hardened to the organization's hardening standard and it is expected to sit behind a firewall, then this information should be documented in the external dependencies section. External dependencies should be documented as follows:

ID - A unique ID assigned to the external dependency.

Description - A textual description of the external dependency.


Example: 

External Dependencies

ID

Description

1

The college library website will run on a Linux server running Apache. This server will be hardened as per the college's server hardening standard. This includes the application of the latest operating system and application security patches.

2

The database server will be MySQL and it will run on a Linux server. This server will be hardened as per the college's server hardening standard. This will include the application of the lastest operating system and application security patches.

3

The connection between the Web Server and the database server will be over a private network.

4

The Web Server is behind a firewall and the only communication available is TLS.


Entry Points

Entry points define the interfaces through which potential attackers can interact with the application or supply it with data. In order for a potential attacker to attack an application, entry points must exist. Entry points in an application can be layered, for example each web page in a web application may contain multiple entry points. Entry points should be documented as follows:

ID - A unique ID assigned to the entry point. This will be used to cross reference the entry point with any threats or vulnerabilities that are identified. In the case of layer entry points, a major.minor notation should be used.

Name - A descriptive name identifying the entry point and its purpose.

Description - A textual description detailing the interaction or processing that occurs at the entry point.

Trust Levels - The level of access required at the entry point is documented here. These will be cross referenced with the trusts levels defined later in the document.


Example: 

Entry Points

ID

Name

Description

Trust Levels

1

HTTPS Port

The college library website will be only be accessible via TLS. All pages within the college library website are layered on this entry point.

(1) Anonymous Web User

(2) User with Valid Login Credentials
(3) User with Invalid Login Credentials
(4) Librarian

1.1

Library Main Page

The splash page for the college library website is the entry point for all users.

(1) Anonymous Web User

(2) User with Valid Login Credentials
(3) User with Invalid Login Credentials
(4) Librarian

1.2

Login Page

Students, faculty members and librarians must log in to the college library website before they can carry out any of the use cases.

(1) Anonymous Web User

(2) User with Login Credentials
(3) User with Invalid Login Credentials
(4) Librarian

1.2.1

Login Function

The login function accepts user supplied credentials and compares them with those in the database.

(2) User with Valid Login Credentials
(3) User with Invalid Login Credentials

(4) Librarian

1.3

Search Entry Page

The page used to enter a search query.

(2) User with Valid Login Credentials

(4) Librarian


Assets

The system must have something that the attacker is interested in; these items/areas of interest are defined as assets. Assets are essentially threat targets, i.e. they are the reason threats will exist. Assets can be both physical assets and abstract assets. For example, an asset of an application might be a list of clients and their personal information; this is a physical asset. An abstract asset might be the reputation of an organization. Assets are documented in the threat model as follows:

ID - A unique ID is assigned to identify each asset. This will be used to cross reference the asset with any threats or vulnerabilities that are identified.

Name - A descriptive name that clearly identifies the asset.

Description - A textual description of what the asset is and why it needs to be protected.

Trust Levels - The level of access required to access the entry point is documented here. These will be cross referenced with the trust levels defined in the next step.


Example: 

Assets

ID

Name

Description

Trust Levels

1

Library Users and Librarian

Assets relating to students, faculty members, and librarians.

1.1

User Login Details

The login credentials that a student or a faculty member will use to log into the College Library website.

(2) User with Valid Login Credentials
(4) Librarian 
(5) Database Server Administrator 
(7) Web Server User Process
(8) Database Read User
(9) Database Read/Write User

1.2

Librarian Login Details

The login credentials that a Librarian will use to log into the College Library website.

(4) Librarian 
(5) Database Server Administrator 
(7) Web Server User Process
(8) Database Read User
(9) Database Read/Write User

1.3

Personal Data

The College Library website will store personal information relating to the students, faculty members, and librarians.

(4) Librarian 
(5) Database Server Administrator 
(6) Website Administrator 
(7) Web Server User Process
(8) Database Read User
(9) Database Read/Write User

2

System

Assets relating to the underlying system.

2.1

Availability of College Library Website

The College Library website should be available 24 hours a day and can be accessed by all students, college faculty members, and librarians.

(5) Database Server Administrator 
(6) Website Administrator 

2.2

Ability to Execute Code as a Web Server User

This is the ability to execute source code on the web server as a web server user.

(6) Website Administrator 
(7) Web Server User Process 

2.3

Ability to Execute SQL as a Database Read User

This is the ability to execute SQL select queries on the database, and thus retrieve any information stored within the College Library database.

(5) Database Server Administrator
(8) Database Read User
(9) Database Read/Write User

2.4

Ability to Execute SQL as a Database Read/Write User

This is the ability to execute SQL. Select, insert, and update queries on the database and thus have read and write access to any information stored within the College Library database.

(5) Database Server Administrator
(9) Database Read/Write User

3

Website

Assets relating to the College Library website.

3.1

Login Session

This is the login session of a user to the College Library website. This user could be a student, a member of the college faculty, or a Librarian.

(2) User with Valid Login Credentials
(4) Librarian

3.2

Access to the Database Server

Access to the database server allows you to administer the database, giving you full access to the database users and all data contained within the database.

(5) Database Server Administrator

3.3

Ability to Create Users

The ability to create users would allow an individual to create new users on the system. These could be student users, faculty member users, and librarian users.

(4) Librarian
(6) Website Administrator

3.4

Access to Audit Data

The audit data shows all audit-able events that occurred within the College Library application by students, staff, and librarians.

(6) Website Administrator


Trust Levels

Trust levels represent the access rights that the application will grant to external entities. The trust levels are cross referenced with the entry points and assets. This allows us to define the access rights or privileges required at each entry point, and those required to interact with each asset. Trust levels are documented in the threat model as follows:

ID - A unique number is assigned to each trust level. This is used to cross reference the trust level with the entry points and assets.

Name - A descriptive name that allows you to identify the external entities that have been granted this trust level.

Description - A textual description of the trust level detailing the external entity who has been granted the trust level.


Example: 

Trust Levels

ID

Name

Description

1

Anonymous Web User

A user who has connected to the college library website but has not provided valid credentials.

2

User with Valid Login Credentials

A user who has connected to the college library website and has logged in using valid login credentials.

3

User with Invalid Login Credentials

A user who has connected to the college library website and is attempting to log in using invalid login credentials.

4

Librarian

The librarian can create users on the library website and view their personal information.

5

Database Server Administrator

The database server administrator has read and write access to the database that is used by the college library website.

6

Website Administrator

The Website administrator can configure the college library website.

7

Web Server User Process

This is the process/user that the web server executes code as and authenticates itself against the database server as.

8

Database Read User

The database user account used to access the database for read access.

9

Database Read/Write User

The database user account used to access the database for read and write access.


Data Flow Diagrams

All of the information collected allows us to accurately model the application through the use of Data Flow Diagrams (DFDs). The DFDs will allow us to gain a better understanding of the application by providing a visual representation of how the application processes data. The focus of the DFDs is on how data moves through the application and what happens to the data as it moves. DFDs are hierarchical in structure, so they can be used to decompose the application into subsystems and lower-level subsystems. The high level DFD will allow us to clarify the scope of the application being modeled. The lower level iterations will allow us to focus on the specific processes involved when processing specific data. There are a number of symbols that are used in DFDs for threat modeling. These are described below:

External Entity
The external entity shape is used to represent any entity outside the application that interacts with the application via an entry point.

DFD external entity.gif 

Process
The process shape represents a task that handles data within the application. The task may process the data or perform an action based on the data.

DFD process.gif 

Multiple Process
The multiple process shape is used to present a collection of subprocesses. The multiple process can be broken down into its subprocesses in another DFD.

DFD multiple process.gif 

Data Store
The data store shape is used to represent locations where data is stored. Data stores do not modify the data, they only store data.

DFD data store.gif 


Data Flow
The data flow shape represents data movement within the application. The direction of the data movement is represented by the arrow.

DFD data flow.gif 

Privilege Boundary
The privilege boundary shape is used to represent the change of privilege levels as the data flows through the application.

DFD privilge boundary.gif 


Example


Data Flow Diagram for the College Library Website 

Data flow1.jpg 

User Login Data Flow Diagram for the College Library Website 

Data flow2.jpg 

Determine and Rank Threats

Threat Categorization

The first step in the determination of threats is adopting a threat categorization. A threat categorization provides a set of threat categories with corresponding examples so that threats can be systematically identified in the application in a structured and repeatable manner.

STRIDE

A threat categorization such as STRIDE is useful in the identification of threats by classifying attacker goals such as:

Spoofing

Tampering

Repudiation

Information Disclosure

Denial of Service

Elevation of Privilege.

A threat list of generic threats organized in these categories with examples and the affected security controls is provided in the following table:


STRIDE Threat List

Type

Examples

Security Control

Spoofing

Threat action aimed to illegally access and use another user's credentials, such as username and password.

Authentication

Tampering

Threat action aimed to maliciously change/modify persistent data, such as persistent data in a database, and the alteration of data in transit between two computers over an open network, such as the Internet.

Integrity

Repudiation

Threat action aimed to perform illegal operations in a system that lacks the ability to trace the prohibited operations.

Non-Repudiation

Information disclosure

Threat action to read a file that one was not granted access to, or to read data in transit.

Confidentiality

Denial of service

Threat aimed to deny access to valid users, such as by making a web server temporarily unavailable or unusable.

Availability

Elevation of privilege

Threat aimed to gain privileged access to resources for gaining unauthorized access to information or to compromise a system.

Authorization


Security Controls

Once the basic threat agents and business impacts are understood, the review team should try to identify the set of controls that could prevent these threat agents from causing those impacts. The primary focus of the code review should be to ensure that these security controls are in place, that they work properly, and that they are correctly invoked in all the necessary places. The checklist below can help to ensure that all the likely risks have been considered.

Authentication:

Ensure all internal and external connections (user and entity) go through an appropriate and adequate form of authentication. Be assured that this control cannot be bypassed.

Ensure all pages enforce the requirement for authentication.

Ensure that whenever authentication credentials or any other sensitive information is passed, only accept the information via the HTTP “POST” method and will not accept it via the HTTP “GET” method.

Any page deemed by the business or the development team as being outside the scope of authentication should be reviewed in order to assess any possibility of security breach.

Ensure that authentication credentials do not traverse the wire in clear text form.

Ensure development/debug backdoors are not present in production code.

Authorization:

Ensure that there are authorization mechanisms in place.

Ensure that the application has clearly defined the user types and the rights of said users.

Ensure there is a least privilege stance in operation.

Ensure that the Authorization mechanisms work properly, fail securely, and cannot be circumvented.

Ensure that authorization is checked on every request.

Ensure development/debug backdoors are not present in production code.

Cookie Management:

Ensure that sensitive information is not comprised.

Ensure that unauthorized activities cannot take place via cookie manipulation.

Ensure that proper encryption is in use.

Ensure secure flag is set to prevent accidental transmission over “the wire” in a non-secure manner.

Determine if all state transitions in the application code properly check for the cookies and enforce their use.

Ensure the session data is being validated.

Ensure cookies contain as little private information as possible.

Ensure entire cookie is encrypted if sensitive data is persisted in the cookie.

Define all cookies being used by the application, their name, and why they are needed.

Data/Input Validation:

Ensure that a DV mechanism is present.

Ensure all input that can (and will) be modified by a malicious user such as HTTP headers, input fields, hidden fields, drop down lists, and other web components are properly validated.

Ensure that the proper length checks on all input exist.

Ensure that all fields, cookies, http headers/bodies, and form fields are validated.

Ensure that the data is well formed and contains only known good chars if possible.

Ensure that the data validation occurs on the server side.

Examine where data validation occurs and if a centralized model or decentralized model is used.

Ensure there are no backdoors in the data validation model.

Golden Rule: All external input, no matter what it is, is examined and validated.

Error Handling/Information leakage:

Ensure that all method/function calls that return a value have proper error handling and return value checking.

Ensure that exceptions and error conditions are properly handled.

Ensure that no system errors can be returned to the user.

Ensure that the application fails in a secure manner.

Ensure resources are released if an error occurs.

Logging/Auditing:

Ensure that no sensitive information is logged in the event of an error.

Ensure the payload being logged is of a defined maximum length and that the logging mechanism enforces that length.

Ensure no sensitive data can be logged; e.g. cookies, HTTP “GET” method, authentication credentials.

Examine if the application will audit the actions being taken by the application on behalf of the client (particularly data manipulation/Create, Update, Delete (CUD) operations).

Ensure successful and unsuccessful authentication is logged.

Ensure application errors are logged.

Examine the application for debug logging with the view to logging of sensitive data.

Cryptography:

Ensure no sensitive data is transmitted in the clear, internally or externally.

Ensure the application is implementing known good cryptographic methods.

Secure Code Environment:

Examine the file structure. Are any components that should not be directly accessible available to the user?

Examine all memory allocations/de-allocations.

Examine the application for dynamic SQL and determine if it is vulnerable to injection.

Examine the application for “main()” executable functions and debug harnesses/backdoors.

Search for commented out code, commented out test code, which may contain sensitive information.

Ensure all logical decisions have a default clause.

Ensure no development environment kit is contained on the build directories.

Search for any calls to the underlying operating system or file open calls and examine the error possibilities.

Session Management:

Examine how and when a session is created for a user, unauthenticated and authenticated.

Examine the session ID and verify if it is complex enough to fulfill requirements regarding strength.

Examine how sessions are stored: e.g. in a database, in memory etc.

Examine how the application tracks sessions.

Determine the actions the application takes if an invalid session ID occurs.

Examine session invalidation.

Determine how multithreaded/multi-user session management is performed.

Determine the session HTTP inactivity timeout.

Determine how the log-out functionality functions.

Threat Analysis

The prerequisite in the analysis of threats is the understanding of the generic definition of risk that is the probability that a threat agent will exploit a vulnerability to cause an impact to the application. From the perspective of risk management, threat modeling is the systematic and strategic approach for identifying and enumerating threats to an application environment with the objective of minimizing risk and the associated impacts.

Threat analysis as such is the identification of the threats to the application, and involves the analysis of each aspect of the application functionality and architecture and design to identify and classify potential weaknesses that could lead to an exploit.

In the first threat modeling step, we have modeled the system showing data flows, trust boundaries, process components, and entry and exit points. An example of such modeling is shown in the Example: Data Flow Diagram for the College Library Website.

Data flows show how data flows logically through the end to end, and allows the identification of affected components through critical points (i.e. data entering or leaving the system, storage of data) and the flow of control through these components. Trust boundaries show any location where the level of trust changes. Process components show where data is processed, such as web servers, application servers, and database servers. Entry points show where data enters the system (i.e. input fields, methods) and exit points are where it leaves the system (i.e. dynamic output, methods), respectively. Entry and exit points define a trust boundary.

Threat lists based on the STRIDE model are useful in the identification of threats with regards to the attacker goals. For example, if the threat scenario is attacking the login, would the attacker brute force the password to break the authentication? If the threat scenario is to try to elevate privileges to gain another user’s privileges, would the attacker try to perform forceful browsing?

It is vital that all possible attack vectors should be evaluated from the attacker’s point of view. For this reason, it is also important to consider entry and exit points, since they could also allow the realization of certain kinds of threats. For example, the login page allows sending authentication credentials, and the input data accepted by an entry point has to validate for potential malicious input to exploit vulnerabilities such as SQL injection, cross site scripting, and buffer overflows. Additionally, the data flow passing through that point has to be used to determine the threats to the entry points to the next components along the flow. If the following components can be regarded critical (e.g. the hold sensitive data), that entry point can be regarded more critical as well. In an end to end data flow, for example, the input data (i.e. username and password) from a login page, passed on without validation, could be exploited for a SQL injection attack to manipulate a query for breaking the authentication or to modify a table in the database.

Exit points might serve as attack points to the client (e.g. XSS vulnerabilities) as well for the realization of information disclosure vulnerabilities. For example, in the case of exit points from components handling confidential data (e.g. data access components), exit points lacking security controls to protect the confidentiality and integrity can lead to disclosure of such confidential information to an unauthorized user.

In many cases threats enabled by exit points are related to the threats of the corresponding entry point. In the login example, error messages returned to the user via the exit point might allow for entry point attacks, such as account harvesting (e.g. username not found), or SQL injection (e.g. SQL exception errors).

From the defensive perspective, the identification of threats driven by security control categorization such as ASF, allows a threat analyst to focus on specific issues related to weaknesses (e.g. vulnerabilities) in security controls. Typically the process of threat identification involves going through iterative cycles where initially all the possible threats in the threat list that apply to each component are evaluated.

At the next iteration, threats are further analyzed by exploring the attack paths, the root causes (e.g. vulnerabilities, depicted as orange blocks) for the threat to be exploited, and the necessary mitigation controls (e.g. countermeasures, depicted as green blocks). A threat tree as shown in figure 2 is useful to perform such threat analysis

Figure 2: Threat Graph

Once common threats, vulnerabilities, and attacks are assessed, a more focused threat analysis should take in consideration use and abuse cases. By thoroughly analyzing the use scenarios, weaknesses can be identified that could lead to the realization of a threat. Abuse cases should be identified as part of the security requirement engineering activity. These abuse cases can illustrate how existing protective measures could be bypassed, or where a lack of such protection exists. A use and misuse case graph for authentication is shown in figure below:

Figure 3: Use and Misuse Case

Finally, it is possible to bring all of this together by determining the types of threat to each component of the decomposed system. This can be done by using a threat categorization such as STRIDE or ASF, the use of threat trees to determine how the threat can be exposed by a vulnerability, and use and misuse cases to further validate the lack of a countermeasure to mitigate the threat.

To apply STRIDE to the data flow diagram items the following table can be used:

TABLE

Ranking of Threats

Threats can be ranked from the perspective of risk factors. By determining the risk factor posed by the various identified threats, it is possible to create a prioritized list of threats to support a risk mitigation strategy, such as deciding on which threats have to be mitigated first. Different risk factors can be used to determine which threats can be ranked as High, Medium, or Low risk. In general, threat risk models use different factors to model risks such as those shown in figure below:


Figure 3: Risk Model Factors

DREAD

In the Microsoft DREAD threat-risk ranking model, the technical risk factors for impact are Damage and Affected Users, while the ease of exploitation factors are Reproducibility, Exploitability and Discoverability. This risk factorization allows the assignment of values to the different influencing factors of a threat. To determine the ranking of a threat, the threat analyst has to answer basic questions for each factor of risk, for example:

For Damage: How big would the damage be if the attack succeeded?

For Reproducibility: How easy is it to reproduce an attack to work?

For Exploitability: How much time, effort, and expertise is needed to exploit the threat?

For Affected Users: If a threat were exploited, what percentage of users would be affected?

For Discoverability: How easy is it for an attacker to discover this threat?

By referring to the college library website it is possible to document sample threats related to the use cases such as:

Threat: Malicious user views confidential information of students, faculty members and librarians.

Damage potential: Threat to reputation as well as financial and legal liability:8

Reproducibility: Fully reproducible:10

Exploitability: Require to be on the same subnet or have compromised a router:7

Affected users: Affects all users:10

Discoverability: Can be found out easily:10

Overall DREAD score: (8+10+7+10+10) / 5 = 9

In this case having 9 on a 10 point scale is certainly a high risk threat

Generic Risk Model

A more generic risk model takes into consideration the Likelihood (e.g. probability of an attack) and the Impact (e.g. damage potential):

Risk = Likelihood x Impact

The likelihood or probability is defined by the ease of exploitation, which mainly depends on the type of threat and the system characteristics, and by the possibility to realize a threat, which is determined by the existence of an appropriate countermeasure.

The following is a set of considerations for determining ease of exploitation:

Can an attacker exploit this remotely?

Does the attacker need to be authenticated?

Can the exploit be automated?

The impact mainly depends on the damage potential and the extent of the impact, such as the number of components that are affected by a threat.

Examples to determine the damage potential are:

Can an attacker completely take over and manipulate the system?

Can an attacker gain administration access to the system?

Can an attacker crash the system?

Can the attacker obtain access to sensitive information such as secrets, PII

Examples to determine the number of components that are affected by a threat:

How many data sources and systems can be impacted?

How “deep” into the infrastructure can the threat agent go?

These examples help in the calculation of the overall risk values by assigning qualitative values such as High, Medium and Low to Likelihood and Impact factors. In this case, using qualitative values, rather than numeric ones like in the case of the DREAD model, help avoid the ranking becoming overly subjective.

Countermeasure Identification

The purpose of the countermeasure identification is to determine if there is some kind of protective measure (e.g. security control, policy measures) in place that can prevent each threat previously identified via threat analysis from being realized. Vulnerabilities are then those threats that have no countermeasures. Since each of these threats has been categorized either with STRIDE or ASF, it is possible to find appropriate countermeasures in the application within the given category.

Provided below is a brief and limited checklist which is by no means an exhaustive list for identifying countermeasures for specific threats.

Example of countermeasures for ASF threat types are included in the following table:

ASF Threat & Countermeasures List

Threat Type

Countermeasure

Authentication

Credentials and authentication tokens are protected with encryption in storage and transit

Protocols are resistant to brute force, dictionary, and replay attacks

Strong password policies are enforced

Trusted server authentication is used instead of SQL authentication

Passwords are stored with salted hashes

Password resets do not reveal password hints and valid usernames

Account lockouts do not result in a denial of service attack

Authorization

Strong ACLs are used for enforcing authorized access to resources

Role-based access controls are used to restrict access to specific operations

The system follows the principle of least privilege for user and service accounts

Privilege separation is correctly configured within the presentation, business and data access layers

Configuration Management

Least privileged processes are used and service accounts with no administration capability

Auditing and logging of all administration activities is enabled

Access to configuration files and administrator interfaces is restricted to administrators

Data Protection in Storage and Transit

Standard encryption algorithms and correct key sizes are being used

Hashed message authentication codes (HMACs) are used to protect data integrity

Secrets (e.g. keys, confidential data ) are cryptographically protected both in transport and in storage

Built-in secure storage is used for protecting keys

No credentials and sensitive data are sent in clear text over the wire

Data Validation / Parameter Validation

Data type, format, length, and range checks are enforced

All data sent from the client is validated

No security decision is based upon parameters (e.g. URL parameters) that can be manipulated

Input filtering via white list validation is used

Output encoding is used

Error Handling and Exception Management

All exceptions are handled in a structured manner

Privileges are restored to the appropriate level in case of errors and exceptions

Error messages are scrubbed so that no sensitive information is revealed to the attacker

User and Session Management

No sensitive information is stored in clear text in the cookie

The contents of the authentication cookies is encrypted

Cookies are configured to expire

Sessions are resistant to replay attacks

Secure communication channels are used to protect authentication cookies

User is forced to re-authenticate when performing critical functions

Sessions are expired at logout

Auditing and Logging

Sensitive information (e.g. passwords, PII) is not logged

Access controls (e.g. ACLs) are enforced on log files to prevent un-authorized access

Integrity controls (e.g. signatures) are enforced on log files to provide non-repudiation

Log files provide for audit trail for sensitive operations and logging of key events

Auditing and logging is enabled across the tiers on multiple servers

When using STRIDE, the following threat-mitigation table can be used to identify techniques that can be employed to mitigate the threats.

STRIDE Threat & Mitigation Techniques List

Threat Type

Mitigation Techniques

Spoofing Identity

Appropriate authentication

Protect secret data

Don't store secrets

Tampering with data

Appropriate authorization

Hashes

MACs

Digital signatures

Tamper resistant protocols

Repudiation

Digital signatures

Timestamps

Audit trails

Information Disclosure

Authorization

Privacy-enhanced protocols

Encryption

Protect secrets

Don't store secrets

Denial of Service

Appropriate authentication

Appropriate authorization

Filtering

Throttling

Quality of service

Elevation of privilege

Run with least privilege

Once threats and corresponding countermeasures are identified it is possible to derive a threat profile with the following criteria:

Non mitigated threats: Threats which have no countermeasures and represent vulnerabilities that can be fully exploited and cause an impact

Partially mitigated threats: Threats partially mitigated by one or more countermeasures which represent vulnerabilities that can only partially be exploited and cause a limited impact

Fully mitigated threats: These threats have appropriate countermeasures in place and do not expose vulnerability and cause impact

Mitigation Strategies

The objective of risk management is to reduce the impact that the exploitation of a threat can have to the application. This can be done by responding to a threat with a risk mitigation strategy. In general there are five options to mitigate threats

Do nothing: for example, hoping for the best

Inform about the risk: for example, warning user population about the risk

Mitigate the risk: for example, by putting countermeasures in place

Accept the risk: for example, after evaluating the impact of the exploitation (business impact)

Transfer the risk: for example, through contractual agreements and insurance

Terminate the risk: for example, shutdown, turn-off, unplug or decommission the asset


The decision of which strategy is most appropriate depends on the impact an exploitation of a threat can have, the likelihood of its occurrence, and the costs for transferring (i.e. costs for insurance) or avoiding (i.e. costs or losses due redesign) it. That is, such decision is based on the risk a threat poses to the system. Therefore, the chosen strategy does not mitigate the threat itself but the risk it poses to the system. Ultimately the overall risk has to take into account the business impact, since this is a critical factor for the business risk management strategy. One strategy could be to fix only the vulnerabilities for which the cost to fix is less than the potential business impact derived by the exploitation of the vulnerability. Another strategy could be to accept the risk when the loss of some security controls (e.g. Confidentiality, Integrity, and Availability) implies a small degradation of the service, and not a loss of a critical business function. In some cases, transfer of the risk to another service provider might also be an option.


블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

출처: http://m.blog.naver.com/mearee/220042040502


================= 원문 =================



JavaProtect V1.5 User Guidebook

 

 

 2014/07/28 - 프로그램이 업데이트 되었습니다. 

자세한 정보는 다음 링크를 이용하세요.

 http://blog.naver.com/mearee/220074899746

 

 

프로그램 다운로드 URL: http://1drv.ms/1nSahuJ

매뉴얼 다운로드 : http://1drv.ms/1lRrRxP

 

 

내용 목차

I.    JavaProtect    4

1.1.    JavaProtect란?    4

1.2.    JavaProtect 환경 최소 요구사항    4

1.3.    JavaProtect V1.5의 기능    5

II.    JavaProtectV1.5 인터페이스    5

2.1. 실행    5

2.2. JavaProtect V1.5 화면 구성    7

 

 

그림목차

[그림 1] 프로그램의 실행    5

[그림 2] 프로그램의 로딩 및 실행직후 화면    5

[그림 3] 프로그램의 GUI    6

[그림 4] 기본화면 GUI    7

[그림 5] 원본파일의 위치 선택    7

[그림 6] 출력폴더의 선택    8

[그림 7] SDK 및 ClassPath의 선택    8

[그림 8] APK SIGN을 위한 Command    8

[그림 9] APK Sign을 위한 Argument    8

[그림 10] Keystore 파일의 위치    8

[그림 11] KeyStore의 명칭    8

그림 12    9

[그림 13] 선택 보호규칙    9

[그림 14] Dex2Jar의 위치선택    9

[그림 16] Dex2Jar의 Argument    10

[그림 17] Jar2Dex의 위치선택    10

[그림 18] Jar2Dex의 Argument    10

[그림 19] Jar파일의 위치선택    10

[그림 20] Jar파일 Argument    10

[그림 21] ZipAlign 위치    10

[그림 22] ZipAlign Argument    10

[그림 23] 이름변경이 안돼야 할 목록들    10

[그림 24] 등록된 이름변경이 안 되야 할 목록들    11

[그림 25] 이름변경이 안되 야할 것들의 설정버튼    11

[그림 26] 이름변경금지 항목의 선택    11

[그림 27] 실행버튼    12

 

 

  1. JavaProtect란?

 

자바프로텍트는 기존 자바로 만들어진 소스코드를 난독화 하여 해당 소스코드를 보호하는 기능을 가지고 있습니다.

자바로 만들어진 프로그램의 경우 플랫폼의 독립성을 위해 바이너리 컴파일을 하는 게 아닌 중간 바이트코드로 컴파일 되기 때문에 디컴파일이 가능합니다.

디컴파일을 하였을 경우 소스코드가 보여지기 때문에 해당 소스코드를 보호하기 위한 난독화가 필요합니다.

JavaProtect 는 APK 및 JAVA로 만들어진 프로그램의 소스코드를 안전하게 보호 할 수 있습니다.

 

본 프로그램은 무료로 배포됩니다.

 

  1. JavaProtect 환경 최소 요구사항

 

표 1 – 요구사항

구분

요구 사항

OS

Windows XP이상

RAM

2GB 이상

Framework

JAVA

HDD

100mb 이상

Network

외부와 연결된 네트워크

 

본 JavaProtect V1.5는 [표 1 – 요구사항]에 나와있는 항목을 필요로 합니다.

APK를 난독화 하실 때에는 JAVA를 필요로 합니다. 또한 라이선스의 검증을 위한 외부와 연결된 네트워크를 필요로 합니다. 물론 무료로 배포되는 프로그램이긴 하나, 1년에 한번씩 라이선스를 재발급 받아 사용해야 합니다. 라이선스를 발급받을 때에 비용은 들지 않습니다.

 

  1. JavaProtect V1.5의 기능

 

표 2 – JavaProtect V1.5의 기능

APK 코드난독화

APK(Android) 파일을 난독화할 수 있습니다.

해당 난독화 파일은 바로 설치/사용할 수 있습니다.

JAR 코드 난독화

JAR 파일을 난독화 할 수 있습니다.


  1. JavaProtectV1.5 인터페이스

 


  1. 실행

 

  1. JavaProtectGUI.exe 실행 파일을 더블클릭 합니다.

     

[그림 1] 프로그램의 실행

  1. 정상적으로 실행 될 경우 [그림]2 와 같이 실행됩니다.

     

[그림 2] 프로그램의 로딩 및 실행직후 화면

 

 

[그림 3] 프로그램의 GUI

 

   

  1. JavaProtect V1.5 화면 구성

     

    1. 기본 화면 구성

[그림 4] 기본화면 GUI

 

  1. 원본파일

[그림 5] 원본파일의 위치 선택


원본파일은 난독화를 해야 할 대상자, 즉 원본파일을 선택하는 위치입니다. 찾아보기를 클릭하여 해당 파일을 선택하시면 원본파일의 선택위치가 바뀐 것을 확인할 수 있습니다.

 

원본 파일에 선택할 수 있는 파일들은 APK 파일, JAR 파일, DEX 파일, ZIP 파일등이 있습니다.

 

  1. 출력폴더

[그림 6] 출력폴더의 선택


해당 원본파일을 난독화 한 후 난독화된 파일을 출력할 위치를 선택합니다. 찾아보기를 클릭하여 해당 폴더를 선택하시면 난독화된 파일의 출력위치가 바뀐 것을 확인 하실 수 있습니다.

 

  1. SDK or ClassPath

[그림 7] SDK 및 ClassPath의 선택


난독화를 하기 위하여 필요한 ClassPath 및 SDK의 위치를 지정합니다.

안드로이드용 APK의 경우, 안드로이드 SDK의 JAR 파일인 android.jar 과 uiautomator.jar를 선택하시면 되고,

Java 프로그램을 난독화 하기 위해서는 Java 설치 폴더의 JRE 디렉토리의 JAR 파일들을 설정해주면 됩니다.

 

  1. SignCommand

[그림 8] APK SIGN을 위한 Command


APK 파일의 경우 설치 시 SIGN을 필수로 필요로 하기 때문에 Sign을 할 프로그램을 선택합니다.

보통 APK Sign을 위해서는 JDK 설치 폴더의 jarsigner.exe 를 이용합니다.

 

  1. SignArgs

[그림 9] APK Sign을 위한 Argument


APK파일의 싸인 Argument 입니다 jarsigner.exe에 맞게 기본 설정되어 있습니다.

 

  1. Keystore 파일

[그림 10] Keystore 파일의 위치


APK 서명을 위한 Keystore 파일을 선택합니다.

 

  1. Key Alias

[그림 11] KeyStore의 명칭


KeyAlias 파일의 명칭을 적어둡니다. 해당 Keystore파일에서 파싱할 Key입니다.

이클립스에서 키 store만들 때 넣었던 문자열입니다.

 

  1. 보호규칙

그림 12

[그림 13] 선택 보호규칙


  1. 패키지이름변경

    해당 난독화시 패키지 이름을 변경할 여부를 선택합니다. 패키지 이름을 감추는 데에 사용합니다.


  2. 클래스이름변경

    클래스 이름을 변경하는데 사용합니다. 디컴파일되어 분석을 할 경우 난이도를 상승시킵니다.


  3. 메소드이름변경

    메소드이름을 변경하는데 사용합니다.


  4. 필드이름변경

    필드 이름을 변경하는 데에 사용합니다.


  5. 디버그정보삭제

    디버그 정보를 삭제합니다.


  6. 시작클래스보호

    시작클래스를 보호합니다. 즉, public static void main() 함수가 들어 있는 클래스의 클래스 이름을 바꾸지 않습니다. 자바 Applet의 경우, Applet 시작 코드가 들어 있는 클래스 이름을 바꾸지 않습니다.


  7. 클래스조각내기

    클래스를 작게 분해하여 여러 클래스로 생성합니다. 디컴파일 되어 분석 시 어렵게 합니다.


  8. 어플릿클래스

    에플릿클래스일경우 체크합니다. Applet class의 경우 꼭 체크해주셔야 합니다.


  9. Native지원

    Native코드를 지원합니다. 만약, native 인터페이스로 선언된 메소드가 있을 경우, 클래스 이름과 메소드 이름을 변경하지 않습니다.


  10. 시작클래스 외 숨기기

    분석을 어렵게 합니다. 어플릿이나 자바 프로그램의 main() 함수가 있는 클래스 이외에는 모두 다른 패키지로 묶어서 버립니다.


  1. Dex2JarCmd

[그림 14] Dex2Jar의 위치선택


APK 파일에서만 사용됩니다.

기본적으로 자바프로텍트에는 Dex2Jar기능이 포함되어 있으나, 추후 DEX의 규격이 바뀌거나 혹은 별도의 Dex2Jar 프로그램을 이용하고자 할 경우에 사용할 수 있습니다.

 

  1. Dex2JarArgs

[그림 16] Dex2Jar의 Argument


APK파일에서만 사용됩니다.

기본적으로 dex2jar 명령어에 대한 전달인자로 설정되어 있습니다.

 

  1. Jar2DexCmd

[그림 17] Jar2Dex의 위치선택


APK 파일에서만 사용됩니다.

기본적으로 자바프로텍트에 jar2dex 기능이 포함되어 있습니다. 별도의 프로그램으로 jar2dex를 이용하고자 할 경우에만 설정해줍니다.

 

  1. Jar2DexArgs

[그림 18] Jar2Dex의 Argument


Jar2Dex의 프로그램이 변경되어 인자 값의 변경이 필요할 경우 사용됩니다.

기본적으로 변경하실 필요가 없습니다.

 

  1. JarCMD

[그림 19] Jar파일의 위치선택


  1. JarArgs

[그림 20] Jar파일 Argument


자바프로텍트에는 기본적으로 패키징기능이 포함되어 있으나, 별도의 APK 패키징을 위한 압축을 할 때 사용하는 명령어 입니다. Zip 이나 jar를 이용하여 압축을 할 수 있으나, 여기서는 jar를 이용하여 패키징화 할 수 있도록 기본 설정되어 있습니다.

 

  1. ZipAlignCmd

[그림 21] ZipAlign 위치


  1. ZipAlignArgs

[그림 22] ZipAlign Argument


기본적으로 자바프로텍트에는 zip alignment 기능이 포함되어 있으나, 별도의 프로그램을 이용하여 zip alignment를 수행하고자 할 경우에 사용합니다.

 

  1. 이름보존목록

[그림 23] 이름변경이 안돼야 할 목록들


프로그램의 실행 시 이름을 보존해야 할 필요성이 있을 때가 있습니다.

하이브리드 앱일경우 Html단에서 호출하는 이름은 변경이 되면 안되기 때문에

해당 제외목록을 확인할 수 있도록 되어있습니다.

제외목록을 추가하기 위해서는 이름보존설정 버튼을 클릭하시면 됩니다.

[그림 24] 등록된 이름변경이 안 되야 할 목록들


등록된 이름을 추가하면 위와 같이 현재 제외되어있는 리스트를 확인 할 수 있습니다.


  1. 이름보존설정

[그림 25] 이름변경이 안되 야할 것들의 설정버튼

 

이름보존을 설정하여 변경되지 말아야 할 메소드이름 또는 클래스이름 등을 지정할 수 있습니다.

[그림 26] 이름변경금지 항목의 선택


이름변경 금지항목의 선택을 통하여 해당 금지항목을 추가 할 수 있습니다.


  1. 실행

[그림 27] 실행버튼


마지막으로 실행버튼을 클릭하면 해당 출력 디렉터리에 해당 난독화된 파일이 생성된 것을 확인 하실 수 있습니다.


블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

Java Decompiler project는 JDK 5 이후의 바이트 코드를 분석하고 디컴파일하기 위해 개발된 툴이다. 


JD-Core는 하나 이상의 .class 파일로 부터 자바 소스코드를 재생성하기 위한 라이브러리이다. JD-CORE는 소스코드를 잃어버렸을때 소스를 복구하기 위해 사용하거나 자바 런타임 라이브러리의 소스를 탐색하기 위해 사용할 수 있다.  자바 5버전의 새로운 기능 - 어노테이션이라던가 enum, generic과 같은 - 도 지원된다. JD-GUI, JD-Eclipse는 JD-Core를 포함하고 있다.


JD-GUI는 .class 파일의 자바소스코드를 표시하는 독립형 그래픽 유틸리티이다.  재빌드된 소스코드에서 메소드나 필드를 즉시 액세스할 수 있다.

JD-Eclipse는 이클립스 플러그인이다.  프로세스를 디버깅하는 동안 자바 소스코드를 볼수 있다.

JD-intelliJ는 intelliJ IDE 플러그인이다.

JD-Core, JD-GUI & JD-Eclipse 는 GPLv3 라이센스 정책이 적용된 오픈소스프로젝트의 산출물이다.


JD-GUI 다운로드

JD-GUI 소스코드 다운로드


JD-Eclipse 다운로드


JD-Eclipse 소스 코드 다운로드

JD-Eclipse 설치 방법

  1. Download and unzip the JD-Eclipse Update Site,
  2. Launch Eclipse,
  3. Click on "Help > Install New Software...",
  4. Click on button "Add..." to add an new repository,
  5. Enter "JD-Eclipse Update Site" and select the local site directory,
  6. Check "Java Decompiler Eclipse Plug-in",
  7. Next, next, next... and restart Eclipse.


JD-IntelliJ 플러그인 다운로드

JD-IntelliJ 소스코드 다운로드

JD-IntelliJ 설치방법

  1. Download the project from Bitbucket.
  2. Import it on IntelliJ IDEA.
  3. Create a new configuration with the type "plugin".
  4. Run the new configuration.



jad를 이용하여 자바 클래스 디컴파일하기


jad158g.win.zip


1. 다운로드 받아서 적당한 위치에 압축을 해제한다.

2. jad.exe 가 저장된 경로를 환경변수의 Path에 추가한다.

3. jad.exe -o -sjava Test.class

4. Test.java 파일이 생성된다.

 


블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

출처: https://www.google.com/about/appsecurity/reward-program/


Google Vulnerability Reward Program (VRP) Rules

We have long enjoyed a close relationship with the security research community. To honor all the cutting-edge external contributions that help us keep our users safe, we maintain a Vulnerability Reward Program for Google-owned web properties, running continuously since November 2010.

Services in scope(대상서비스)

 *.google.com

 *.youtube.com

 *.blogger.com


In principle, any Google-owned web service that handles reasonably sensitive user data is intended to be in scope. This includes virtually all the content in the following domains:

  • *.google.com
  • *.youtube.com
  • *.blogger.com

Bugs in Google-developed apps and extensions (published in Google Play, in iTunes, or in the Chrome Web Store) will also qualify.

On the flip side, the program has two important exclusions to keep in mind:

  • Third-party websites. Some Google-branded services hosted in less common domains may be operated by our vendors or partners (this notably includeszagat.com). We can’t authorize you to test these systems on behalf of their owners and will not reward such reports. Please read the fine print on the page and examine domain and IP WHOIS records to confirm. If in doubt, talk to us first!
  • Recent acquisitions. To allow time for internal review and remediation, newly acquired companies are subject to a six-month blackout period. Bugs reported sooner than that will typically not qualify for a reward.

Qualifying vulnerabilities (보상대상 취약점)


- XSS(Cross-site scripting)

- CSRF(Cross-site request forgery)

- Mixed-content scripts(HTTPS페이지에서 HTTP를 로드하는 경우 발생하는 ㅟ약점)

- Authentication or authorization flaws

- Server-side code execution bugs


Any design or implementation issue that substantially affects the confidentiality or integrity of user data is likely to be in scope for the program. Common examples include:

  • Cross-site scripting,
  • Cross-site request forgery,
  • Mixed-content scripts,
  • Authentication or authorization flaws,
  • Server-side code execution bugs.

Note that the scope of the program is limited to technical vulnerabilities in Google-owned browser extensions, mobile, and web applications; please do not try to sneak into Google offices, attempt phishing attacks against our employees, and so on.

Out of concern for the availability of our services to all users, please do not attempt to carry out DoS attacks, leverage black hat SEO techniques, spam people, or do other similarly questionable things. We also discourage the use of any vulnerability testing tools that automatically generate very significant volumes of traffic.

Non-qualifying vulnerabilities   (대상이 아닌 취약점)


- 샌드박스 도메인 내에서 발생하는 XSS

- URL redirection

- 합법적인 프록싱

- 거의 발생하지 않는 사용자의 인터렉션을 요구하는 경우

- 로그아웃 CSRF

- 이전 버번의 브라우저와 플러그인에서만 발생하는 경우

- 배너나 버전 정보 노출


New! Visit our Bug Hunter University page dedicated to common non-qualifying findings and vulnerabilities.

Depending on their impact, some of the reported issues may not qualify. Although we review them on a case-by-case basis, here are some of the common low-risk issues that typically do not earn a monetary reward:

  • Cross-site scripting vulnerabilities in “sandbox” domains (read more.) We maintain a number of domains that leverage the same-origin policy to safely isolate certain types of untrusted content; the most prominent example of this is *.googleusercontent.com. Unless an impact on sensitive user data can be demonstrated, we do not consider the ability to execute JavaScript in that domain to be a bug.
  • Execution of owner-supplied JavaScript in Blogger. Blogs hosted in *.blogspot.com are no different from any third-party website on the Internet. For your safety, we employ spam and malware detection tools, but we do not consider the ability to embed JavaScript within your own blog to be a security bug.
  • URL redirection (read more.) We recognize that the address bar is the only reliable security indicator in modern browsers; consequently, we hold that the usability and security benefits of a small number of well-designed and closely monitored redirectors outweigh their true risks.
  • Legitimate content proxying and framing. We expect our services to unambiguously label third-party content and to perform a number of abuse-detection checks, but as with redirectors, we think that the value of products such as Google Translate outweighs the risk.
  • Bugs requiring exceedingly unlikely user interaction. For example, a cross-site scripting flaw that requires the victim to manually type in an XSS payload into Google Maps and then double-click an error message may realistically not meet the bar.
  • Logout cross-site request forgery (read more.) For better or worse, the design of HTTP cookies means that no single website can prevent its users from being logged out; consequently, application-specific ways of achieving this goal will likely not qualify. You may be interested in personal blog posts from Chris Evansand Michal Zalewski for more background.
  • Flaws affecting the users of out-of-date browsers and plugins. The security model of the web is being constantly fine-tuned. The panel will typically not reward any problems that affect only the users of outdated or unpatched browsers. In particular, we exclude Internet Explorer prior to version 9.
  • Presence of banner or version information. Version information does not, by itself, expose the service to attacks - so we do not consider this to be a bug. That said, if you find outdated software and have good reasons to suspect that it poses a well-defined security risk, please let us know.

Monetary rewards aside, vulnerability reporters who work with us to resolve security bugs in our products will be credited on the Hall of Fame. If we file an internal security bug, we will acknowledge your contribution on that page.

Reward amounts   (보상금액)  $100~$20,000

New! To read more about our approach to vulnerability rewards you can read our Bug Hunter University article here.

Rewards for qualifying bugs range from $100 to $20,000. The following table outlines the usual rewards chosen for the most common classes of bugs:

CategoryExamplesApplications that permit taking over a Google account [1]Other highly sensitive applications [2]Normal Google applicationsNon-integrated acquisitions and other sandboxed or lower priority applications [3]
Vulnerabilities giving direct access to Google servers
Remote code executionCommand injection, deserialization bugs, sandbox escapes$20,000$20,000$20,000$1,337 - $5,000
Unrestricted file system or database accessUnsandboxed XXE, SQL injection$10,000$10,000$10,000$1,337 - $5,000
Logic flaw bugs leaking or bypassing significant security controlsDirect object reference, remote user impersonation$10,000$7,500$5,000$500
Vulnerabilities giving access to client or authenticated session of the logged-in victim
Execute code on the clientWebCross-site scripting
MobileCode execution
$7,500$5,000$3,133.7$100
Other valid security vulnerabilitiesWebCSRF, Clickjacking
MobileInformation leak, privilege escalation
$500 - $7,500$500 - $5,000$500 - $3,133.7$100

[1] For example, for web properties this includes some vulnerabilities in Google Accounts (https://accounts.google.com).

[2] This category includes products such as Google Search (https://www.google.com and https://encrypted.google.com), Google Wallet (https://wallet.google.com), Google Mail (https://mail.google.com), Google Inbox (https://inbox.google.com), Google Code Hosting (code.google.com), Chrome Web Store (https://chrome.google.com), Google App Engine (https://appengine.google.com), Google Admin (https://admin.google.com), Google Developers Console (https://console.developers.google.com), and Google Play (https://play.google.com).

[3] Note that acquisitions qualify for a reward only after the initial six-month blackout period has elapsed.

The final amount is always chosen at the discretion of the reward panel. In particular, we may decide to pay higher rewards for unusually clever or severe vulnerabilities; decide to pay lower rewards for vulnerabilities that require unusual user interaction; decide that a single report actually constitutes multiple bugs; or that multiple reports are so closely related that they only warrant a single reward.

We understand that some of you are not interested in money. We offer the option to donate your reward to an established charity. If you do so, we will double your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.

Investigating and reporting bugs

When investigating a vulnerability, please, only ever target your own accounts. Never attempt to access anyone else's data and do not engage in any activity that would be disruptive or damaging to your fellow users or to Google.

New! Visit our Bug Hunter University articles to learn more about sending good vulnerability reports.

If you have found a vulnerability, please contact us at goo.gl/vulnzPlease be succinct: the contact form is attended by security engineers and a short proof-of-concept link is more valuable than a video explaining the consequences of an XSS bug. If necessary, you can use this PGP key.

Note that we are only able to answer to technical vulnerability reports. Non-security bugs and queries about problems with your account should be instead directed toGoogle Help Centers.

Frequently asked questions

Q: What if I found a vulnerability, but I don't know how to exploit it?

A: We expect that vulnerability reports sent to us have a valid attack scenario to qualify for a reward, and we consider it as a critical step when doing vulnerability research. Reward amounts are decided based on the maximum impact of the vulnerability, and the panel is willing to reconsider a reward amount, based on new information (such as a chain of bugs, or a revised attack scenario).

Q: How do I demonstrate the severity of the bug if I’m not supposed to snoop around?

A: Please submit your report as soon as you have discovered a potential security issue. The panel will consider the maximum impact and will chose the reward accordingly. We routinely pay higher rewards for otherwise well-written and useful submissions where the reporter didn't notice or couldn't fully analyze the impact of a particular flaw.

Q: I found an outdated software (e.g. Apache or Wordpress). Does this qualify for a reward?

A: Please perform due diligence: confirm that the discovered software had any noteworthy vulnerabilities, and explain why you suspect that these features may be exposed and may pose a risk in our specific use. Reports that do not include this information will typically not qualify.

Q: Who determines whether my report is eligible for a reward?

A: The reward panel consists of the members of the Google Security Team. The current permanent members are Artur Janc, Eduardo Vela Nava, Jeremy Zimmer, Martin Straka, and Michal Zalewski. In addition there is a rotating member from the rest of our team.

Q: What happens if I disclose the bug publicly before you had a chance to fix it?

A: Please read our stance on coordinated disclosure. In essence, our pledge to you is to respond promptly and fix bugs in a sensible timeframe - and in exchange, we ask for a reasonable advance notice. Reports that go against this principle will usually not qualify, but we will evaluate them on a case-by-case basis.

Q: I wish to report an issue through a vulnerability broker. Will my report still qualify for a reward?

A: We believe that it is against the spirit of the program to privately disclose the flaw to third parties for purposes other than actually fixing the bug. Consequently, such reports will typically not qualify.

Q: What if somebody else also found the same bug?

A: First in, best dressed. You will qualify for a reward only if you were the first person to alert us to a previously unknown flaw.

Q: My employer / boyfriend / dog frowns upon my security research. Can I report a problem privately?

A: Sure. If you are selected as a recipient of a reward, and if you accept, we will need your contact details to process the payment. You can still request not to be listed on our public credits page.

Q: What is bughunter.withgoogle.com?

A: The dashboard for the participants in Google’s VRP program. It dynamically creates the hall of fame, i.e., the 0x0A and honorable mentions lists.

Q: Do I need a profile on bughunter.withgoogle.com to participate in the VRP?

A: No. You can participate in the VRP under the same rules without the need of a profile. However, if you want your name to be listed in the 0x0A or the honorable mentions lists, you need to create a profile.

Q: Is the profile data publicly available?

A: Yes. The profile holds the data that is currently already available now on our hall of fame, i.e., on the 0x0A and honorable mentions lists. You can always leave these fields blank.

Q: How is the honorable mentions list sorted?

A: The hall of fame is sorted based on the volume of valid bug submissions, the ratio of valid vs. invalid submissions, and the severity of those submissions.

We are unable to issue rewards to individuals who are on sanctions lists, or who are in countries (e.g. Cuba, Iran, North Korea, Sudan and Syria) on sanctions lists. You are responsible for any tax implications depending on your country of residency and citizenship. There may be additional restrictions on your ability to enter depending upon your local law.

This is not a competition, but rather an experimental and discretionary rewards program. You should understand that we can cancel the program at any time and the decision as to whether or not to pay a reward has to be entirely at our discretion.

Of course, your testing must not violate any law, or disrupt or compromise any data that is not your own.

블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

HTTPS와 SSL 인증서

2015.08.27 07:59

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

SSO

2015.08.25 23:55

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

데이터베이스 암호화

2015.08.22 21:16

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

티스토리 툴바