Win a copy of Secure Financial Transactions with Ansible, Terraform, and OpenSCAP this week in the Cloud/Virtualization forum!

Ramesh Nagappan

Author
+ Follow
since May 06, 2003
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ramesh Nagappan

Your code looks perfect. There is a possibility the username (cn) you provided is not granted access to perform a search ! To test the code.. use "cn=Directory Manager" and its password. Your LDAP administrator should able to help here or if you have access to your LDAP console try search using the same username and see what happens.

-R
15 years ago
Dear JavaRanchers,

We take this opportunity to thank you all for posting questions and all your excellent feedback about the book.

Both Chris and I thoroughly enjoyed discussing with you all...and as expected JavaRanch always been a great resource to share and reenergize our Java thoughts.

Please feel free to contact us at our email address - authors@coresecuritypatterns.com for all book-related or other questions where we we would able to help you.

Goodluck,

Ramesh & Chris.
15 years ago

Originally posted by Jignesh Patel:
Hi Jignesh....my comments are inline <RN>,

I went through the sample chapter.

<RN> Thanks for reading through the chapter. As the chapter title speaks..it is all about introducing the reader to a structure design methodology, patterns-driven and best practices based security approaches and how to perform security assessments for Java/J2EE applications</RN>


I like the idea of explaining Security Patterns using the concept of
Security Wheel with Unified Process(UP).


<RN>
The concept of Security Wheel represents the core security principles, which Java architect/developer must consider while designing an application. Some of those principles may not apply...but still it cannot be ignored..you consider them as Trade-offs.
We chose UML and UP, as they are considered as de-facto standard for representing application design models.
We did receive lot of positive feedback about both Security Wheel and Secure UP.
</RN>

Is Signle Access Point differ then SSO?

<RN>
Yes - both are different in terms of scope.
Single Access Point is a security pattern defined by Joseph Yoder and Jerry Barcalow (based on their security patterns research paper). It enforces a single point of access to a business service typically refers to a login page to an application.
SSO is an ability of an user to log in once to multiple applications that would ordinarily require their own separate logins. It allows an user to access disparate resources that can be accessed via centralized interface or portal. This is accomplished via creating an unique security token during authentication which is trusted by participating applications.. all subsequent requests are presented using the security token so that the user gains consistent user experience by doing single login access to multiple applications...all without reauthentication.
</RN>


I don't understand PEP(Policy Enforcement Point), may be book explains
in more detail.

<RN>
The policy enforcement point is a security entry point where all security functions are initiated ...such as authentication, authorization, audit functions based on the source of the request, transport protocol and incoming content. Policy Decision Point (PDP) is where all decisions are made to allow a request to be processed or not.
The books drills lot of details about PEP and PDP...in Chapter 7.
</RN>


I don't know what do you mean by SQL Injections?

<RN>

SQL Injections are all about exploiting data input in web applications...where a hacker breaks into the application by injecting malicious data or a condition that initiates a malformed SQL query via the JDBC statement executed on the underlying database.
We recommend the use of Intercepting Validator to thwart SQL and other malformed data injection attacks.
</RN>


Secure Pipe pattern seems very usefull for web services security.

Alchemy of security Business Application is good to understand implementation flow.



<RN> Thanks for the comments </RN>


Description for implementing Security Policy in Check in item is interesting. Actually Check In item gives managerial aspect of implementing security.


<RN> Thanks again </RN>


For testing you suggested open source framework is prferable compare to
propriatory. But you haven't mentioned about any of open source framework can be used for white box testing of security.


<RN> We did recommend use of selected Opensource as well as commercial implementations for security testing in Chapter 14. We certainly don't want to give biased opinions when it comes to choosing software </RN>


Goodluck

/Ramesh

[ January 13, 2006: Message edited by: Jignesh Patel ]


[ January 13, 2006: Message edited by: Ramesh Nagappan ]
15 years ago
<RN> These are PHISHING attacks pretty much common now...it can happen via both a malicious web-site or an email perpetuated scripts. These attacks can be restricted through Browser privacy settings (Cooking Acceptance, URL re-directing, Image acceptance Policies). When you store frequently visited web sites and their passwords or related information ...make sure they are encrypted. But still, there are lot of ways to connect with a computer while surfing !!! Personal firewalls and content-filtering are good options.

In J2EE Web application development you can choose to encrypt cookies or encoded URLs (URLRewriting) ! Encrypting cookies and encoding URLs or combination of both can be done...these are usually very much vendor specific mechanisms and it is not mandated by the Servlet & JSP specifications. Encrypting SessionIDs, Identifying Client HostIDs and using TIMESTAMPS are also considered as best practices to avoid session theft, session hijacking...once again, these are usually vendor-specific.In addition, Always use SSL communication to ensure that client is interacting via secure channel.

Cookie encryption, encrypted session IDs, URL encoding, timestamping, client IP identification are all very much light-weight and more or less CPU/memory intensive (assuming encryption bit-strength is comsidered medium)...so it should not impact performance or even your overall budget. If you want to perform encryption and decryption at wire-speed then you may consider using SSL/Crypto accelerators....that's a bit pricy but it helps.

The optimal solution is all about striking a balance between your security trade-offs and budget :-) !!! Perform a risk analysis and estimate the cost of a known risk and vulnerability...how it relates to your business application... Now decide !!!

</RN>
15 years ago

Originally posted by Vibha Jindal:
How are these patterns different from the J2EE patterns?
Are these patterns applicable to J2EE applications as well?


<RN>
To support J2EE application development and address their core security requirements... Core Security Patterns builds on Core J2EE Patterns to ensure that security risks and vulnerabilties are identified and mitigated with appropriate Java based safeguards and countermeasures. These security patterns ensures end-to-end security including all J2EE Tiers and its core components.
</RN>


I have 6 years experience in J2EE and would love to know the best practices in security as I've always felt that security is neglected in many applications.


<RN>
Besides patterns and design strategies, the book identifies 101 Security best practices associated with J2EE applications and Web services.
The security best practices and pitfalls are intended for proactive security assessment of J2EE application design, implementation, deployment, testing and monitoring.
</RN>


Are these patterns limited to Authentication or Authorization as well?


<RN>
NO. The patterns looks into all possible weakest links of an application in terms of security risks and vulnerabilities and relate them with the fundamental security requirements such as...... Authentication, Authorization, Confidentiality, Integrity, Policy, Auditing, Logging, PKI, Availability, Compliance, Single sign-on, identity management, provisioning, Hardening & Minimization..etc.
</RN>

-Ramesh


Regards,
Vibha

15 years ago
Eric,

One of the primary goals of our book is to enrich the user with Java Security Mechanisms ground-up and then show how to apply Java Security Mechanisms using Security Design Patterns. In a real world scenario, it helps a Java architect/developer to proactively identify the risks and vulnerabilities during application development and resolves them via Patterns and ist associated design Strategies. Most Security Patterns builds on the J2EE/GoF Patterns and it does follow the common patterns vocabulary to represent security mechanisms.

Goodluck

/Ramesh
15 years ago
I would suggest you to look at ..how you created you Directory Context...for example.... Check your SECURITY_PRINCIPAL it should look like this !!! You may choose a different cn (Directory Manager is not recommended in production)

Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://localhost:389");
env.put(Context.SECURITY_AUTHENTICATION,"simple");
env.put(Context.SECURITY_PRINCIPAL,"cn=Directory Manager");
env.put(Context.SECURITY_CREDENTIALS,"password");
DirContext ctx = new InitialDirContext(env)



Then perform Context.bind for craeting or searching for user objects...for example to create user (which I picked from old code to create user in Sun Directory).

User MyUser = new User("jranch","Java","Rancher","ou=JavaGurus", "jranch@coresecuritypatterns.com");
ctx.bind("uid=jranch,ou=People,o=coresecuritypatterns.com", myUser);

I think, your code crashed during the bind operation....

To get SECURITY_PRINCIPAL in the code...for example in a Servlet, you may use HttpRequest.getUserPrincipal() method.

goodluck.
[ January 13, 2006: Message edited by: Ramesh Nagappan ]
15 years ago
John,

Ofcourse, the book provides a check-list (numerous to write here) for pro-active security assessment at every stages of the application development process and prior to production deployment. It does identify all other enviromental dependencies (weakest links) that impacts an organization's application security in terms of Network security (Firewalls, IDS, Router ACLs), Transport security (SSL,IPSec), Host environment (OS Hardening & Minimization), users/groups/roles (Realms), PKI/Crypto hardware (Encryption/DSIG), Identity provider (Policy, SSO,Federation), Honeypots, Monitoring, Auditing and Reporting for regulatory compliance (ex. Sarbanes-Oxley, GLBA, HIPPA).

In each "Patterns & Design Strategies" the book lists the "Best practices and Pitfalls" considerations for application development, production deployment, monitoring, auditing and reporting. The book contains 101 bestpractices to support the various aspects of Java/J2EE architecture and Web services.

Hope this helps.

/Ramesh
15 years ago
Your are welcome.

C++/C based applications and Mainframes are not going away....they do live forever to save Jobs.

Goodluck

/Ramesh
15 years ago
Good points and well said...Tina and John.
15 years ago

Originally posted by John Hembree:
I'm not sure that you understood my question and quite possibly I didn't understand your answer.

I was looking for something along the lines of any information regarding the complete solution. Let's say I use this book and built the perfect application addressing every security issue within the realms of Java. The program was flawless, but then I installed the app on a server that I don't keep patched. It sits out in a DMZ or possibly inside my network without any firewall rules. The database server is sitting on the same box as the app. I don't know what else would be bad for me to do with my strong app but having compromised the other areas of my solution?

Do you have any generalized instructions of other steps I can take to secure my solution not just the application? Larger clients may have a security deartment that keeps all of things things in mind when deploying a solution. Is there anything that I can use within the book to guide me to other areas of security?




John,

Technically speaking the focus of our book and the identified patterns and best practices are targeted to support architects and developers involved with J2SE/J2EE/J2ME/JavaCard, XML Web services, Identity Management and Service Provisioning.

I am bit confused about 'What you mean as "other areas of security" ? Are you referring to other OS platforms or application languages ? Are you referring to Network or Physical security ? Could you please list those areas ? Let us see where the book can help.

For better understanding about the goals of this book, you may visit our book web site and take a glimpse of the free chapter and our presentations to RSA Security and JavaONE conferences.

/Ramesh
15 years ago
In Java Multi-threading, the Java's thread security is enforced by the SecurityManager class...this means that the security policies of the threaded program can be established when an instance of the class is instantiated. You may choose to set all the security policies (permissions) in a Security Policy file and enforce them with the runtime using a command-line option or programmatically. (i.e -Djava.security.policy=my.policy).

Particularly, For verifying access protection we can use the two Java SecurityManager methods ...checkAccess(Thread t) and checkAccess(ThreadGroup tg)..these methods throw an SecurityException if there is a violation of security policy occurred.

Read our Chapter 3 - Java 2 Platform Security for more info.

Does this help.

/Ramesh
[ January 12, 2006: Message edited by: Ramesh Nagappan ]
15 years ago

Originally posted by Scott Selikoff:
Are there any chapters that discuss or comment about proprietary solutions? I share your view that J2EE should be vendor independent, but I've been in situations where I had to use vendor solutions and I'm curious how they fit into the mold or if they are so different, that they don't fit anywhere at all.



<RN>

We carefully avoided not to discuss about non-standard or proprietary vendor solution. In some cases to illustrate examples (for Web services, Identity Management and Service provisioning), we discussed security patterns using popular open-source Java frameworks such as Apache Struts, Spring, Axis, OpenSAML and OpenSPML.

</RN>
15 years ago

Originally posted by Tina Coleman:
I was disappointed to not get to see a table of contents and index for the book out on Amazon. I know that's not likely the authors' doing, but passing along that feedback. Speaking as someone who's done a good bit of .NET programming of late, I wonder if the authors could speak to how much of the text is J2EE-specific, and how much would be more widely applicable. I expect that since this is a patterns book, it should be more widely applicable. Definitely interested in some of the various topics listed in the book blurbs.



<RN>
Please refer to the Table of Contents posted in the book Web site - http://www.coresecritypatterns.com. The authors have no idea how amazon gets info !
Most patterns can be applied to Microsoft .NET platform based apps (Chris and I are parallely working on it, but we would like to test them as proven solution equivalent to J2EE before we disclose it to .NET community..so pleas stay tuned).
</RN>
[ January 12, 2006: Message edited by: Ramesh Nagappan ]
15 years ago