FaisalK
Lithium Alumni (Retired)
Joined 15 years ago
User Profile
User Widgets
Contributions
Re: REST: Authentication ticket
It's a clever hack but please beware of couple of things: 1. Adding any portion of user controlled input can introduce potential for security issues such as cross site scripting. In this case the action ticket is being carved from the URL and injected into the page DOM which might result in injection. The cleanest way to avoid injection might be to html encode the ticket value. The action ticket should never contain special characters. The action ticket might have an underscore but that char is usually not encoded which should make things easier. 2. The action ticket is basically there to provide an anti-automation mechanism and also used as a CSRF ticket. There are various action tickets are there considered sensitive and some that are considered non-sensitive. In this case this action ticket is associated to a non-sensitive action such as marking things read/unread (and that's why it's exposed in the URL). It should be noted that exposing sensitive action tokens is not a good idea and should never be put into the URL where is can be unintentionally exposed. The Lithium platform will never do this by design, however, Devs need to be aware of this risk. -FK236ViewsSign in to react to this post0CommentsRe: LiQL injection attacks and quotes in Rest API 2.0
Your design choices should not try to override what information is presented to the user solely on constructing a LiQL query. When using restadmin you should keep that principle in mind even more front and center. Think of restadmin as the exec() equivalent, just b/c it's there doesn't mean it's safe to use for every situation (unless you absolutely know what you are doing). You have raised some very astute points, thanks for a very exciting and well informed discussion on this important topic. Feel free to open up a Support case and if you like I can call you to discuss further. And last but not least, sorry for a shameless plug but I'm hiring a Lead Security Engineer, do you know anyone? Your kind of skill set and knowledge is essential to be successful at this role (based in San Francisco, CA). -FaisalViewsSign in to react to this postCommentsRe: LiQL injection attacks and quotes in Rest API 2.0
Another excellent point. You are correct again, OR true=true might return everything but only to the extent what the user's permissions should allow them to see. Nothing more, nothing less. By design and by default, the user is able to interact with the API and get exactly the same information he or she is allowed to see via the GUI. In other words, your design choices should not try to override what information is presented to the user solely on constructing a LiQL query.ViewsSign in to react to this postCommentsRe: LiQL injection attacks and quotes in Rest API 2.0
I agree in principle, however, this is no different than coding in Java or JS or any other language. Incorporating untrusted user input is never a good idea. And like many of those other languages, it's left up to the developer, freemarker in this case, to incorporate the security best practices (?html, js_string, etc). This type of customization is not considered a user level task, it should only be attempted by a trained and knowledgeable person like yourself.ViewsSign in to react to this postCommentRe: LiQL injection attacks and quotes in Rest API 2.0
Excellent post, Hattesen. It's a general best practice that any user input be escaped and encoded as appropriate and according to the syntax in which it will appear before it's processed or used in any part of the community. This includes all untrusted input such as any part of the URL, any input fields, any HTTP headers, search terms, etc. This gets a bit tricky with labels and tags allowing single or double quotes as you have already pointed out. Re: your SQL injection concern - LiQL's syntax is very similar to a SQL statement. You are absolutely right again that tainted user input could definitely influence a LiQL query statement in freemarker templates. However, a major difference being that influencing the LiQL query will not give you access to the underlying SQL tables/db schema. That's because the LiQL query (REST API V2) is an abstraction layer which essentially maps to predefined objects and not SQL tables, for instances messages, authors, boards, etc. For every query we look at each of the fields to ensure that they match the object definition for the provided collection name. Influencing the syntax of the query will only allow an attacker to maneuver within the confines of prepackaged objects restricted through the lens of permissions assigned to the session. Back to your question about the query syntax. This syntax will result in an error message. SELECT id, body FROM messages WHERE labels.text = 'don't_do_this' However, this syntax will *NOT* result is an error. SELECT id, body FROM messages WHERE labels.text = "don't_do_this"ViewsSign in to react to this postCommentsRe: Users Online Count Explosion!
Hi Derek, Sorry that your original point got lost in the shuffle. "Why users online spiked to 15k this morning? Did I miss something? What are you not telling me?" Have you tried reaching out to your TAM or created a support ticket to look into this? In general, there could be many reasons why this could have happened, including but not limited to, bot traffic, crawlers, security testing, etc. It could even be tied to legitimate activity such as overly ambitious monitoring, performance testing, etc. -FaisalViewsSign in to react to this postCommentRe: Users Online Count Explosion!
This is a security concern. Please block this IP address immediately.ViewsSign in to react to this postComments
236Views
0CommentsYou’ve seen all recent content