1. Application Security Chao-Hsien Chu, Ph.D.
College of Information Sciences and Technology
The Pennsylvania State University
University Park, PA 16802
Theory 
Practice
Learning by
Doing
IST 515

2. Castle Analogue We can learn a lot from building Castle.
Build with security in mind
Have defense in depth, not just from the outside
May have to give up some efficiency to have good security
Hard to add on later, if don’t start first

3. Objectives
Understand the principles related to designing secure information system / applications.
Understand the security and controls that should be included in system development process, databases, data warehousing, knowledge-based systems, and web applications.
What are the proper and secure means of designing and controlling applications.
Understand malicious code and software, such as computer viruses and how they can be introduced into the computing environment.
Understand mechanisms that can be used to prevent, detect, and correct malicious code and their attacks.

4. Readings (1)
Tipton, H. and Henry, K. (Eds.), Official (ISC)2 Guide to the CISSP CBK, Domain 8 - “Application Security,” (Required). By Robert M. Slade. Auerbach, 2007.
Amer, S. H., Humphries, J. W. and Hamilton, Jr, J. A., “Survey: Security in the System Development Life Cycle,” Proceedings of the 2005 IEEE Workshop on lnfomation Assurance and Security, United States Military Academy, West Point, NY, pp (Required).
Baskerville, R., “Information Systems Security Design Methods: Implications for Information Systems Development,” ACM Computing Surveys, Vol. 25, No 4, December 1993, pp
Wikipedia, “Application Security.” (Required)

5. Readings (2)
Wikipedia, “Software engineering.”
Wikipedia, “Capability Maturity Model.”
Wikipedia, “Systems Development Life Cycle.”
Wikipedia, “Object-oriented Programming.”
Wikipedia, “Buffer Overflow.”

6. Readings (3)
Wikipedia, “Covert Channel.”
Wikipedia, “Malware”.
The Department of Homeland Security and SRI International, “The Crimeware Landscape: Malware, Phishing, Identity Theft and Beyond,”
Wikipedia, “Database security.”

7. Scope of Application Security
The domain covers the following topics:
The processes and activities regarding the planning, programming and management of software and systems.
The controls that may be installed within software systems to ensure the confidentiality, integrity and availability of either software or data under processing.
The concepts involved in databases and database management and web applications.
The proper and secure means of designing and controlling applications.
Malicious Software - Malware.

8. Current Situations (1)
Information security has traditionally emphasized the system level access controls, recent has focused attention on applications.
Software security is a major problem. A great many of information security incidents involve software vulnerabilities in one form or another.
Few security professionals have significant systems development or programming background. At the same time, training in programming and development tends to emphasize speed and productivity over quality, let alone considerations of security.

9. Current Situations (2)
A troublesome characteristic of application software may affect the computing and business environment broadly.
Legacy code, as well as design decisions taken decades ago, are still involved in current systems and interact with new technologies and operations in ways that may open additional vulnerabilities.
Malware is much more than a mere nuisance: it is now a major security risk. A recent FBI computer crime survey indicated that malware accounted for a third of the total cost to business of all reported incidents.

10. Threats to the Software Environment
Buffer Overflow.
Citizen Programmers.
Covert Channel.
Malicious Code/Malware.
Memory Reuse (Object Reuse).
Executable Content/Mobile Code.
Social Engineering.
Time of Check/Time of Use (TOC/TOU).
Trapdoor/Backdoor.

11. Buffer Overflow
Buffer overflow problem occurs when a program fills up its buffer of memory with more data than the buffer can hold. When the program begins to write beyond the end of the buffer, the program’s execution path can be changed. This can lead to the insertion of malicious code (e.g., patch the kernel) that can be used to destroy data or to gain administrative privileges on the program or machine.

12. How a Buffer Overflow Works
A program that is the target of an attack is provided with more data than the application was intended or expected to handle.
The attacked program (target) overruns the memory allocated for input data, and writes the excess data into the system memory.
The excess data can contain machine language instructions so that when the next step is executed, the attack code, like a Trojan horse or other type of malicious code, is run.

13. Citizen Programmers
Citizen programmers refer to the cases in which casual users are allowed access to programming languages in order to modify the software program. Visual Basic, included in the Microsoft Office suite, is often used by citizen programmers to develop their applications or extend existing ones.
Citizen programmers are unlikely to be trained in, or bound by, system development practices that involve proper application design, change control, and support for the application. Therefore, application development in such a manner is likely to be chaotic and lack any form of assurance in regard to security.

14. Covert Channel
A covert channel or confinement problem is an information flow issue. It is a communication channel allowing two cooperating processes to transfer information in such a way that it violates the system’s security policy.
It is any flow of information -- intentional or inadvertent -- that enables an observer not authorized to have the information to infer what it is or that it exists. This is primarily a concern in systems containing highly sensitive information.

15. Types of Covert Channels
A covert storage channel involves the direct or indirect reading of a storage location by one process and a direct or indirect reading of the same storage location by another process. Typically, a covert storage channel involves a finite resource, such as a sector on a disk that is shared by two subjects at different security levels.
A covert timing channel depends upon being able to influence the rate that some other process is able to acquire resources such as the CPU, memory, or I/O devices. The variation in rate may be used to pass signals. Timing channels are normally considerably less efficient than storage channels because they have reduced bandwidth and are usually more difficult to control.

16. Memory Reuse (Object Reuse)
This is a problem related to memory management. The problem occurs because residual information remain in memory when a section of memory is reassigned to a new process after a previous process is finished with it, a security violation may occur.
Memory management involves sections of memory allocated to one process for awhile, then deallocated, then reallocated to another process. When memory is reallocated, the operating system should ensure that memory is zeroed out or completely overwritten before it can be accessed by a new process. Thus, there is no residual information in memory carrying over from one process to another.

17. Mobile Code
"Mobile Code" is computer code sourced from remote, possibly "untrusted" systems, but executed on your local system. The concept of "mobile code" has been called by many names: mobile agents, mobile code, downloadable code, executable content, active capsules, remote code, and others. All these deal with the local execution of remotely sourced code.
Examples of mobile code include scripts (JavaScript, VBScript), Java applets, ActiveX controls, Flash animations, Shockwave movies (and Xtras), and macros embedded within Microsoft Office documents.
Mobile code can also download and execute in the client workstation via . Mobile code may download via an attachment (e.g., macro in a Word file) or via an HTML body (e.g., JavaScript). For example, the ILOVEYOU, TRUELOVE, and AnnaK viruses/worms all were implemented as mobile code (VBScript in a .vbs attachment that executed in Windows Scripting Host).

18. Social Engineering
Social engineering is the act of manipulating a person to accomplish goals that may or may not be in the target’s best interest. This may include obtaining information, gaining access, or getting the target to take certain action.
Every time you try to get someone to do something that is in your interest, you are engaging in social engineering. From children trying to get a toy from their parents to adults trying to land a job or score the big promotion, all of it is a form of social engineering.
Due to the mystery surrounding this dark art many people are afraid of it, or they feel they will never be able to accomplish a successful social engineering test.

19. Time of Check/Time of Use (TOC/TOU)
This is a type of asynchronous attack that occurs when some control information is changed between the time the system security functions check the contents of variables and the time the variables actually are used during operations.
For example, a user logs on to a system in the morning and is fired later in the day. As a result of the termination, the security administrator removes the user from the user database. Because the user did not log off, he or she still has access to the system and might try to disrupt operations or cause damage.

20. Trapdoor/Backdoor (1)
A trapdoor or backdoor is a hidden mechanism that bypasses access control measures. It is an entry point into a program that is inserted in software by programmers during the program’s development to provide a method of gaining access into the program for modification if the access control mechanism malfunctions and locks them out. (In this situation, it may also be called a maintenance hook.)

21. Trapdoor/Backdoor (2)
They can be useful for error correction, but they are dangerous opportunities for unauthorized access if left in a production system. A programmer or someone who knows about the backdoor can exploit the trapdoor as a covert means of access after the program has been implemented in the system. An unauthorized user may also discover the entry point while trying to penetrate the system

22. Software Engineering
Software development and maintenance is the dominant expenditure in information systems. Because of the expenses associated with software development, industry research began to provide the best methods of reducing costs, which subsequently led to the discipline of software engineering.
Software engineering simply stated that software products had to be planned, designed, constructed, and released according to engineering principles. It included software metrics, modeling, methods, and techniques associated with the designing of the system before it was developed, tracking project progress through the entire development process.

23. Software Capability Maturity Model (CMM)
Developed by Carnegie Mellon Software Engineering Institute (SEI) in 1986.
The SW-CMM framework establishes a basis for evaluation of the reliability of the development environment.
It is assumed that good practices can be repeated. If an activity is not repeated, there is no reason to improve it.
Theory suggests that the more mature the development process, the more likely it is to have more robust and security software.

24. Software Capability Maturity Model
Organizations must commit to having policies, procedures, and practices and to using them so that the organization can perform in a consistent manner.
Practices need to be defined in such a manner as to allow for transfer across project boundaries.
Quantitative objectives are established for tasks. Measures are established, done, and maintained to form a baseline from which an assessment is possible.
Practices are continuously improved to enhance capability (optimizing).

25. Five CMM Maturity Levels
Level 1 - Initiating - Informal processes, ad hoc development, competent people and heroics.
Level 2 - Repeatable - Project management process and practices are institutionalized.
Level 3 - Defined - Integration of technical and management processes, organizational support.
Level 4 - Managed - Product and process improvement, quantitatively controlled.
Level 5 - Optimizing - Continuous process improvement is institutionalized.

26. Benefits of Higher Level CMM
Improved software quality
Reduced life cycle time
More accurate scheduling and meeting milestones
Proactive planning and tracking
Better security, fewer bugs, if institutionalized

27. Software Development Phases
Project initiation and planning
Functional requirements definition
System design specifications
Build (develop) and document
Acceptance
Transition to production (installation)
Operations and maintenance support (post-installation)
Revisions and system replacement

28. Security in Project Initiation Phase
Identify Security Needs:
Classification and criticality of
information/applications
Basic security objectives
Security controls workload
Identify
User Needs
Initial Risk Analysis:
Threats/Vulnerabilities/Risks
Analyze technical, operational, and economical feasibility of security alternatives
Estimate security-related costs/benefits
Evaluate
Alternatives
Identify Security Framework:
Essential security issues and risks
Determination of service level agreements
Select/Approve Approach

29. Notice
Because of the time constraint, I will not continue to cover the remaining slides. As you can see, there are more materials that we can cover in a class lesson. If you are interested in the topic, please read the materials by yourself

30. Security in Project Initiation Phase
Does particular information have special value or require special protection?
Has the system owner determined the information’s value? What are the assigned classifications?
Will application operation risk exposure of sensitive information?
Will control of output displays or reports require special measures?
Will data be generated in public or semipublic places? Are controlled areas required for operation?

31. Security in Functional Requirements Phase
Prepare
Project Plan
Security Areas in Project Plan:
Configuration and access controls
Audit trails
Define Security Requirements:
Tied into the risk analysis and contingency plan
Threats, vulnerabilities, risks
Security control points
Preliminary contingency planning
Develop Functional Requirements
Preliminary Security Test Plan:
Test methods and resources
Identify evaluation criteria and controls to be tested
Preliminary
Test Plan
Include Security Requirements in RFP and Contracts:
Ensure service level agreement and maintenance contracts meet security
Hardware and software backups and escrow
Select Acquisition Strategy
Establish Formal
Functional Baseline
Functional Baseline Has Security Requirements

32. Security in Design Phase
Define Security Specifications :
System/subsystem/interface
Program/database/hardware and firmware/ network
Develop Detailed Design
Update Security Test Plan :
Develop security test procedure
Test security under abnormal and illegal circumstances
Update Testing Goals and Plans
Establish Formal
Baseline/quality Controls and Requirements
Include security area in formal baseline documentation and quality assurances

33. Security in Deployment Phase
Write or procure and install security-related code:
Control access to code
Identify/document code
Construct Source Code From Detailed Design Specifications
Perform unit tests and evaluate security-related code
Perform and Evaluate Unit Tests
Implement Detailed Design into Final System
Ensure approved security components in formal baseline are included

34. Security in Acceptance Phase
Test System Components
Test security components
Test security in integrated system
Assess functional operations and performance
Identify test failures
Analyze test results against security requirements
Validate System Performance
Install System
Install security code with necessary modifications
Document security controls
User guides must specify access control and protection requirements for sensitive data
Operations/Maintenance manuals
Prepare Project Manuals
Conduct acceptance test:
Last chance to detect security weakness or vulnerabilities
Perform
Acceptance Test
Accept System
Accept/verify project security

35. System Development Methods
Waterfall Models:
- Structured programming development (SDM).
- Spiral Model.
- Cleanroom
Iterative Development:
- Prototyping.
- Modified Prototype Model (MPM).
- Rapid Application Development (RAD).
- Joint Analysis Development (JAD).
- Exploratory Model.

36. System Development Methods
Other Methods and Models:
- Computer-aided Software Engineering (CASE).
- Component-based Development.
- Reuse Model.
- Extreme Programming.

37. Waterfall Model
The waterfall method is the oldest method for developing software systems.
Each phase contains a list of activities that must be performed and documented before the next phase begins.
The disadvantage of the model is that it demands a heavy overhead in planning and administration, and requires patience in the early stages of a project. Also, because each phase must be completed before the next, it can inhibit a development team from pursuing concurrent phases or activities.

38. Waterfall Model
Usually, this method is not good for projects that must be developed in quick turnaround time periods (generally less than six months).
The waterfall model is considered to be the paradigm for the styles known as noniterative models.
From the perspective of security, noniterative models are preferred for systems development.

39. Waterfall Method SDLC System requirements (Validation)
Software requirements (Validation)
Analysis (Verification)
Program design (Verification)
Coding (Unit test)
Product Integration (Verification)
Implementation (System test)
Operations & maintenance (Revalidation)

40. Spiral Model Progress – Angular dimension Cost – Radial dimension
Plans – Lower left quadrant
Objectives, means and constrains - Upper left quadrant
Prototyping, modeling and simulations – Upper right quadrant
Final development stages - Lower right quadrant

42. Threats to the Software Environment
Buffer Overflow.
Citizen Programmers.
Covert Channel.
Malicious Code/Malware.
Memory Reuse (Object Reuse).
Executable Content/Mobile Code.
Social Engineering.
Time of Check/Time of Use (TOC/TOU).
Trapdoor/Backdoor.

43. Special Considerations
Java Security
Object-oriented Programming
Distributed Object-oriented Systems
Database Security
Knowledge-based systems security
Web Application Security
Software Protection Mechanisms
Audit Assurance Mechanisms.
Configuration Management
Certification
Accreditation
Security Controls

44. Java Security (1)
The Java programming language implements some specific security provisions.
Verifier (or interpreter), which helps to ensure type safety. It is primarily responsible for memory and bounds checking.
Class loader, which loads and unloads classes dynamically from the Java runtime environment.
Security manager, which acts as a security gatekeeper protecting against rogue functionality.

45. Java Security (2)
Java Certification Path API for building and validating certification paths and managing certificate revocation lists.
Java GSS-API for securely exchanging messages between communication applications using Kerberos. Support for single sign-on using Kerberos is also included.
Java Authentication and Authorization Service (JASS), which enables services to authenticate and enforce access controls upon users.

46. Java Security (3)
Java Cryptography Extension (JCE) provides a framework and implementation for encryption, key generation, and key agreement, and message authentication code (MAC) algorithms.
Java Secure Socket Extension (JSSE) enables secure Internet connections. It implements a Java version of the Secure Socket Layer (SSL) and Transport Layer Security (TLS) protocols and includes functionality for data encryption, server authentication, message integrity, and optional client authentication.

47. Object Oriented Programming
OOP is a programming method that makes a self-sufficient object.
The object is a block of preassembled programming code in a self-contained module.
The module encapsulates both data and the processing instructions that may be called to process the data. Once a block of programming code is written, it can be reused in any number of programs.

48. OO Terms Message Method Behavior Class Instance Inheritance Delegation
Polymorphism
Polyinstantiation

49. Object-Oriented Security (1)
In object-oriented systems, objects are encapsulated. Encapsulation protects the object by denying access to view what is located inside the object.
Encapsulation of the object does provide protection of private data from outside access. For security purposes, no object should be able to access another object’s internal data.
On the other hand, it could be difficult for system administrators to apply the proper policies to an object if they cannot identify what the object contains.

50. Object-Oriented Security (2)
Some of the security issues can be found in the use of polyinstantiation, polymorphism, and inheritance.
Polyinstantiation allows for iteratively producing a more defined version of an object by replacing variables with values (or other variables). Thus, multiple distant differences between data within objects are done to discourage low-level objects from gaining information at a high level of security.
It is also the technique used to avoid covert channels based on inference by causing the same information to exist at different classification levels.

51. Object-Oriented Security (3)
Polymorphism refers to a programming language’s ability to process objects differently depending on their data type.
The term is sometimes used to describe a variable that may refer to objects whose class is not known at compile time, but will respond at runtime according to the actual class of the object to which they refer.
Even though polymorphism seems straightforward, if used incorrectly, it can lead to security problems.

52. Object-Oriented Security (4)
Inheritance allows a programmer to build a new class similar to an existing class without duplicating all the code. The new class inherits the old class’s definitions and adds to them. This can help decrease program development time — what works for the superclass will also work for the subclass.
Multiple inheritances can introduce complexity and may result in security breaches for object accesses. Issues such as name clashes and ambiguities must be resolved by the programming language to avoid a subclass inheriting inappropriate privileges from a superclass.

53. Key Characteristics of OOP (1)
Encapsulation (Also Known as Data Hiding). A class defines only the data it needs to be concerned with. When an instance of that class (i.e., an object) is run, the code will not be able to accidentally access other data, which is generally seen as positive in terms of security.
Polymorphism. Objects may be processed differently depending on their data type. Unfortunately, this has implications for security that must be carefully assessed.

54. Key Characteristics of OOP (2)
Inheritance. The concept of a data class makes it possible to define subclasses of data objects that share some or all of the main (or super) class characteristics. If security is properly implemented in the high-level class, then subclasses should inherit that security.
Polyinstantiation. Specific objects, instantiated from a higher class, may vary their behavior depending upon the data they contain. Therefore, it may be difficult to verify that inherited security properties are valid for all objects. However, polyinstantiation can also be used to prevent inference attacks against databases, because it allows different versions of the same information to exist at different classification levels.

55. Distributed Object-Oriented Systems
Distributed development architectures allow applications to be divided into pieces that are called components, and each component can exist in different locations. This development paradigm allows programs to download code from remote machines onto a user’s local host in a seamless manner to the user.
Common Object Request Broker Architecture (CORBA), Java Remote Method Invocation (JRMI), Enterprise JavaBean (EJB), and Distributed Component Object Model (DCOM).

56. Software Protection Mechanisms
Security Kernels.
Processor Privilege States.
Security Controls for Buffer Overflows.
Controls for Incomplete Parameter Check and Enforcement.
Memory Protection.
Covert Channel Controls.
Cryptography.
Password Protection Techniques.

57. Software Protection Mechanisms
Inadequate Granularity of Controls.
Control and Separation of Environments.
Time of Check/Time of Use (TOC/TOU).
Social Engineering.
Backup Controls.
Software Forensics.
Malicious Code/Malware Controls.
Virus Protection Controls.
Mobile Code Controls.
Sandbox.
Programming Language Support.

58. Audit and Assurance Mechanisms
Information Integrity.
Information Accuracy.
Information Auditing.
Certification and Accreditation.
Information Protection Management.
Change Management.
Configuration Management.

59. Certification (1)
Certification is the technical evaluation of security compliance of the information system within its operational environment: the endorsement by the users and managers that the system/application meets their functional requirements.
Certification also involves how well the system performs its intended functional requirements.

60. Certification (2)
The certification or evaluation document should contain an analysis of the technical and nontechnical security features and countermeasures and the extent to which the software or system meets the security requirements for its mission and operational environment
The certification process is followed by accreditation.

61. Accreditation
The accreditation process reviews the certification information and grants the official authorization to place the information system into operational use. It is the formal approval by senior management.
The U.S. National Institute of Standards and Technology (NIST) has developed a document (SP ) that recommends a certification and accreditation process and procedures.

62. Vulnerabilities of Certification
Organizations and users cannot count on the certified product being free of security flaws. Because new vulnerabilities are always being discovered, no product is ever completely secure.
Most software products must be securely configured to meet certain protection mechanisms.
Certifications are not the definitive answer to security. Information system security depends on more than just technical software protection mechanisms, such as personnel and physical security measures.

63. Configuration Management
Identifying and controlling components of an every evolving systems
– Configuration item
– Version
– Building
– Build list
– Software Library

64. Malicious Code/Malware
Software designed specifically to include functions for penetrating a system, breaking security policies, or to carry malicious or damaging payloads.
“… a huge category of unwanted code…. Electronic burglar tools like password crackers, traffic sniffers, keystroke loggers, data scroungers and remote access Trojans (RATs) are being used by attackers both inside and outside organizations to capture passwords, spy on network traffic, record private communications, and stealthily receive and transmit unauthorized commands to and from remote hosts.”

65. Types of Malicious Code
Worms.
Hoax.
Trojan horses.
Remote Access Trojan (RAT).
Rootkits.
DDoS Zombies
Logic Bomb.
Spyware and Adware.
Pranks.
Virus:
File infector or file-infecting virus.
Boot sector infector or virus.
System infector.
Multipartite virus.
virus.
Macro virus.
Script virus.

66. Malware Protection Do not double-click on attachments.
When sending attachments, provide a clear and specific description as to the content of the attachment.
Do not blindly use the most widely used products as a company standard.
Disable Windows Script Host, ActiveX, VBScript, and JavaScript. Do not send HTML-formatted .
Use more than one scanner, and scan everything.

67. Malware Protective Tools
Scanners.
Activity Monitors.
Heuristic Scanners.
Change Detection.
Antimalware Policies.

68. Database Vulnerabilities and Threats
Aggregation.
Bypass attacks.
Compromising database views used for access control.
Concurrency.
Data contamination.
Deadlocking.
Denial-of-service.
Improper modification of information.
Inference.
Interception of data.
Polyinstantiation.
Query attacks.
Server access.
Time of check/time of use (TOC/TOU).
Web security.
Unauthorized access.

69. DBMS Controls Lock Controls: Access Controls:
Page locking: an entire memory page is locked.
Table locking: an entire table is locked.
Row locking: a row of data is locked.
Field locking: the single field that is being changed is locked.
Discretionary Access Controls (DACs).
Mandatory Access Controls (MACs).
Access Matrix.
View-Based Access Controls.
Grant and Revoke Access Controls.

70. Aggregation and Inference
Aggregation - users combine individual pieces of information
Inference - using the clues to figure out the larger story

71. Preventing Aggregation and Inference in databases
Containers - placing data in logical containers and controlling access rights
Cell Suppression - hiding cells that contain sensitive info (Salary)
Partitioning - implementing views with limited info
Noise and perturbation – Putting false/misleading info in database
Context dependent access control - looks at previous access and try to detect inference possibilities before allowing other access
Zero Knowledge Proof - make sure information given does not give up other information

72. Knowledge Management
The application of artificial intelligence techniques to decision support.
Workflow management.
Business process modeling.
Document management.
Databases and information systems.
Knowledge-based systems.
Knowledge discovery in databases (KDD).
Online analytical processing (OLAP).

73. Artificial Intelligence
Expert systems - mimic human experts, based on knowledge of experts
– Cannot learn on own
– Need to make sure they don’t give away to much information
Neural networks - based on human brain structure (neurons), pattern recognition
– Can apply more weights to different scenarios
– Can piece together patterns humans might miss

74. Security Controls for KM
Protecting the knowledge base as you would any database.
Routinely verifying the decisions based on what outcomes are expected from specific inputs.
If using a rule-based approach, changes to the rules must go through a change control process.
If the data output seems suspicious or out of the ordinary, perform additional and different queries to verify the information.
Making risk management decisions because decisions that are based on data warehouse analysis techniques may be incorrect.
Developing a baseline of expected performance from the analytical tool.

75. Web Application Threats
Web applications are subject to all of the threats and protection mechanisms discussed elsewhere.
Web applications are specifically vulnerable because of their accessibility, access to database information, or transaction processing.
Most attacks are conducted at the application level, either against the Web server application itself, in-house scripts, or common front-end applications used for E-commerce.

76. Web Application Protection
Having a particular assurance sign-off process for Web servers.
Hardening the operating system used on such servers (removing default configurations and accounts, configuring permissions and privileges correctly, and keeping up to date with vendor patches).
Extending Web and network vulnerability scans prior to deployment.
Passively assessing intrusion detection system (IDS) and advanced intrusion prevention system (IPS) technology
Using application proxy firewalls, and disabling any unnecessary documentation and libraries.

77. Web Application Protection
Ensure that administrative interfaces are removed or secured appropriately.
Only allow access from authorized hosts or net works, and use strong (possibly multifactor) user authentication.
Do not hard code the authentication credentials into the application itself and ensure the security of the credentials.
Use account lockout and extended logging and audit, and protect all authentication traffic with encryption.
Ensure that the interface is at least as secure as the rest of the application, and most often secure it at a higher level.

78. Web Application Protection
Ensure that the proxies are able to deal with problems of buffer overflows, authentication issues, scripting, submission of commands to the underlying platform, encoding issues (such as Unicode), and URL encoding and translation.
The proxy firewall may have to address issues of data submission to in-house and custom software, ensuring validation of input to those systems.
Cookies or URL data, which must be both protected and validated. If using cookies, always encrypt them.
Validate all input and output.
Fail secure (closed).

79. Web Application Protection
Make your application or system as simple as possible.
Use secure network design.
Use defense in depth.
Do not cache secure pages.
Confirm that all encryption used meets industry standards.
Monitor your code vendors for security alerts.
Log any and all critical transactions and milestones.
Handle exceptions properly
Do not trust any data from the client.
Do not automatically trust data from other servers, partners, or other parts of the application.