Jim Manico

George,

One more thing....

> I also feel that you should say something more in the book about IDOR

I would read the access control chapter for that, especially the permission centric and data centric access control discussions. That is the real way to address this issue. Most IDOR issues root cause is a weak access control mechanism. When dealing with these complex issues in a legacy app there is only one path to security - a LOT of hard work.

Many will tell you to put up a "object reference map" to deal with IDOR. That might be a quick fix but it's a weak one. What you really need is a data-contextual permission-based access control system like we see in Apache Shiro, the NIST ABAC standards, and other emerging tools and standards.

Aloha,
Jim

George,

Looks like we are mostly on the same page. A few final notes from me.

1) I really do not want to get deep into criticism of CSRFGuard, I would rather focus on what I feel are positive patterns. I am happy to discuss this with you offline if necessary. I did keep it out of the book intentionally.
2) As men of intelligence we can respectfully disagree. I do stand by the four sentences or so where I discuss the DOR issues with untrusted-data-driven table names and column names in queries. I have run into this anti-pattern in several significant applications. Once in the 90's at the worlds largest company at the time, then in the 2000's at one of the worlds largest social media apps at the time, and then recently in a OSS project. I intentionally do not want to point out the exact project (it's now fixed) since I prefer to focus on the good and not criticize.
3) However, I do think I need to expand on what other portions of a query cannot be parameterized for certain database vendors. I plan to take the table/column name section and put it in a new more verbose section that goes over "what to do when you cannot parameterize" in more detail.

Is there anything else lingering that we need to discuss, George?

Aloha,
Jim

George,

So in summary - I think your concerns about chapter 5 is spot on. That's a big mistake and I'm making the change today in my second edition transcript.

Here is the mistake in the book:

"The client is now responsible for saving and sending this random value value in both the request (as a hidden form field or other request parameter) and in a cookie. The cookie should be at least HTTPOnly since JavaScript code should never need to access this value."

I am changing this section to:

"The client is now responsible for saving and sending this random value value in both the request (as a hidden form field or other request parameter) and in a cookie. The cookie must not be HTTPOnly so JavaScript code can read the cookie and place the same value in another part of the request. Due to same-origin policy, only code delivered from the same domain will be allowed to access cookie data."

In addition to this change, I'm adding a section on CORS in chapter 1 or similar.

Did I address all of your concerns?

George, you rock. I love this level of detail from you. Is that all you got? Bring in on. What other nits do you see?

I'm jim@manico.net and if you want a free copy of the book to give to one of your friends, let me know. I'll ink in the changes by hand before I send it.

Aloha,
Jim

George,

I think you misread the Direct Object Reference section in the SQL injection chapter. Here is the exact paragraph that I submitted to McGraw-Hill.

"There are situations where Query Parameterization is not possible in code. These exceptions are rare but do come up in legacy code. For example, table names and column names are not parameterizable for some database vendors. Although this situation leads one to ask, "Why is untrusted data driving a column name or table name?" they are often used by developers to created reports which only include certain columns or allow end users to specify custom sort options. This pattern can be considered to be the OWASP Top Ten 2014 risk, Insecure Direct Object Reference. When it is necessary to rapidly fix vulnerabilities in legacy code, and Query Parameterization is not possible, sometimes another defense such as input validation can be used to get around this limitation."

So, there are times that using the PreparedStatement class to bind certain variables during Query Parameterization is not possible. For example, if your query contains table names or column names that are driven by user input, then you simply cannot bind those varables in some databases. In fact, when you let a user drive a column name, it's a case of Direct Object Reference and is a vulnerability in and of itself independent of the injection.

So George, I stand by this section and the intention behind it. I will try to clarify it a bit more in the second edition.

George,

Great feedback. I appreciate you taking the time to provide such rich detail.

> If the malicious site evil.com can send requests to vulnerable.com with session riding, why does it not issue beforehand a GET to render the form, harvest the CSRF token, and then submit the POST.

This is not possible. Harvesting the token is only possible via cross site scripting on the vulnerable site itself. Evil.net does NOT send the request to vulnerable.com, it HOSTS that request. The evil request to vulnerable.com lands in the users browser and submits the request. Evil.com has no way to see that result. Make sense?

> The answer to this is that the Same Origin policy forbids evil.com to access content from vulnerable.com.

Exactly. I will make this clarification in the second edition. I agree, we need to clean this up!

> But one cannot just comeup with this answer, if the same origin policy has not been introduced in the book.

Agreed. We need a good section on CORS early on and will add that to the second edition. I'll be sure to give you attribution.

> And they should make a reference to the OWASP CSRF Guard Project, it is THE flagship project afterall!!!

I am not a fan of the architecture of that project, I did not include it *on purpose*. I would rather folks use the built-in defense seen in most frameworks or do it manually. This was a conscious choice to not include it. I find it to be a rather weak and problematic project, especially the fragile JavaScript based injection method. But I do not want to get into why I do NOT like things, I'd rather focus on the good - hence the book, I hope.

> Finally to close Chapter 5, the authors should review the Stateless CSRF Defense section.
> In their coverage of the double submit cookie solution, they write that the csrf cookie should be HttpOnly.

This is a mistake. We fixed this already and you will see that fix in the next edition.

> they speak about stateless webservices and applications that want to keep nothing in their httpSession,
and they dont speak about popular Javascript frameworks, which make heavy use of the technique. This is kind of weird...

ok, we will mention those frameworks next edition, easy to add.

> Finally in chapter 7, section Defence in Depth, the authors present the "Insecure Direct Object Reference" Attack as a special case of SQL injection.
> Specifically, a case of SQL injection where the injected part is in the "order by clause".
> However, the "Insecure Direct Object Reference" Attack is something different and is not necessarily restricted to SQL databases.

George, I did not state that Direct Object Reference was a special case of SQL Injection. I think you misread this section. I explained myself in detail in the next post.

> Failing to describe the problem properly they also fail to present proper solutions, like the ESAPI RandomAccessReferenceMap class.

As a side note, ESAPI is so far from production quality and is no longer maintained so I do not suggest using it in production for most folks.

> Also, I probably sound too strict but the book was great it was by far my best read for 2014

This was not strict at all, it's great help! Thanks kindly for your deep feedback. You are mostly "spot-on". I will be sure to make these changes in the second edition and give you full attribution for these suggestions.

paul nisset wrote:Hi ,

What strategy would you recommend for security in a REST application?
Is passing a token via http headers (once user is authenticated ) ,the best way ?

Thanks,
Paul

Yes, sending a token in a header is reasonable, but that token should be like a session and only have a limited like.

For more info see:

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

Aloha,
Jim

B. Katz wrote:Greetings Jim and August,

Silviu Burcea wrote:And the last one: we cannot prevent every single attack on Earth ... how much security effort means secure enough?

While there are no clear-cut definitions that state "If 'x' is your system, then 'y' is what you need to be secure...", during this race that the governments have been running to be at the top of the Cyber-powers, they have been coming up with some good guidelines to check against your own applications and systems to see how serious you should be about security, called FIPS-199. (Q.v. NIST FIPS-199 Final PDF)

In a nutshell, it checks three aspects of a given system/dataset/application, namely Confidentiality, Integrity and Availability, against what it would be like if any of those aspects were compromised, and gives a rating to how bad the damage would be considered.

That should give you a good base to start from as to how serious you should take the security of your applications and systems.

HTH.

FIPS 999 is a very high level document and gives you very little instruction to build a secure web application.

Joel Thompson wrote:I was reading somewhere that w/ kerberos certificates you can pass these from the issuer (say website A.com) and inspect them on website b.com for single-signon approach. Also, what would be the approach to integrate with Windows networking, so that if they signed on to the windows domain a kerberos certificate would be created and then presented to the 2nd website b.com and SSO would work too (I'm guessing only via IE, unless there are some plugins available for chrome for this.) I'm hoping to discuss some details with cookies and or transports to understand this type of solution.

I'm looking for an architectural answer and real software that can do this. I'm using Weblogic Server (OHS for webserver) and I'd be interested in discussions with Jboss and Apache too.

Does your book cover this SSO type topic?

Thanks!

We cover session management for a normal web application situation but we do not cover SSO based session management.

Comal Rajagopalaratnam Muthukumar wrote:Hi Jim(Author)

As always,this time also I rushed through the contents of the book to see if it tempts me to buy the book even if i do not rather be declared to receive free , but the negative trend prevailed since there appears to be no Examples provided or at least some topics like appendix where the author always throws his liberal help to the readers/users by such similar topics.
Any example is explained .

With Best Luck
As
CRMK

I do not understand your question, can you try that again?

Janeice DelVecchio wrote:When I worked in desktop support, there was a guy who had a notebook of all his passwords. In the notebook, he also kept his "answers" to his security questions.

I made a comment that some answers can be guessed. So he said, "why do you think I write them down?" -- implying that he didn't even know the answers, thus defeating the purpose. If his notebook were burned, he'd have no means of recovery.

I have a list of lies I keep in my head. My high school mascot? First car make/model/color? Street I grew up on? Best friend's name? All lies. Always the same lie so I can remember.

I would suggest the use of a password manager as well.

Jeanne Boyarsky wrote:From the one factor thread:

Jim Manico wrote:Last, if you really do not want to implement it, then you need to consider "account lockout" to keep brute force attacks at bay. Account lockout CAN be used to Denial of Service your site so be careful.

This is the design we used to prevent brute force login attempts on this site. I'm curious what weaknesses there are in it. All I can think of is that if you can present a fake IP, you could still do denial of service for logins. Even that wouldn't affect users who were logged in or anonymous users. And it would have to be kept up hour after hour.

My concern for any kind of IP based blocking strategy is that sometimes you have thousands of users behind one IP address, like a large hotel, a large company or some ISP's. In these situations, failed logins from one IP may occur faster than expected.

Abhay Agarwal wrote:Welcome to Java ranch !!

Why thank you! I've been keeping up with all questions on the security track the last 2 days and will continue to do so all well. Aloha!

Junilu Lacar wrote:

Jim Manico wrote:This defense to protect against phishing is completely useless and many companies are dropping it. A phishing site could take your username, fetch the image, and display it on the phishing site. It's not a good security control.

Huh, now that I think about it, you're right. All an attacker needs to do is steal my username and then he'd still be able to masquerade as the real site and trick me into entering my password.

Exactly! The phishing site itself would get your username, go grab the image, and relay it back. It's not that tough to do....

Abhay Agarwal wrote:Does book also describes different security features that we can apply to Servlets, EJB, Web Services etc. For example - Security in Web service is a very big topic. TO what extent does Security details are covered for these Java programming starlets [ servlets, ejb, web services].

The books focus is on web applications. Many of the techniques apply to webservices as well, but web applications was the focus (and title) of the book.

Abhay Agarwal wrote:I read the description of book on Amazon. Seem like most of the topics are covered.
I want to know which application server [ Tomcat, Weblogic, JBoss] was used to explain different web based security mechanisms ?

We coverer your custom application code, not security of configuring the container.