Re: [ANN] clojure-sec

2013-11-18 Thread ronen 
First note that Im not a security expert so take my advice with a grain of 
salt, 

There are couple of middlewares that are worth checking out (in addition to 
friend):

* https://github.com/weavejester/ring-anti-forgery
* https://github.com/myfreeweb/ring-ratelimit

Regarding SQL injection quoting 
OWSAP
:

   - All queries should be parametrized.
   - All dynamic data should be explicitly bound to parametrized queries.
   - String concatenation should never be used to create dynamic SQL.

It looks like https://github.com/clojure/java.jdbc there is such 
separation, 

Regarding XSS you can escape html 
on
 
the server side but following 
OWSAP
 is 
recommended

It would be nice to have a website dedicated for security best practices in 
Clojure webapps, 

Thanks

On Monday, November 18, 2013 9:19:56 PM UTC+2, wm.ma...@gmail.com wrote:
>
> This list seems somewhat inactive, which I find a bit surprising, but I am 
> very interested in one particular aspect of security when I build Clojure 
> apps.
>
> Right now my interest is in building REST web services and web 
> applications backed by a relational database with something like Angular or 
> Backbone at the front-end. I'm therefore interested in applying best 
> practices in securing web applications for the public internet.
>
> I don't have a deep background in security, but as a seasoned Java 
> developer I have a good idea of some of the security considerations for web 
> applications, and I agree with another post here that OWASP is a very 
> useful resource. My specific interests in security are mainly mitigations 
> against:
>
> 1. SQL injection;
> 2. Cross-site scripting;
> 3. Request forgery.
>
> When it comes to the many libraries available for Clojure I struggle to 
> find good information on these topics, so I'm unsure what is my 
> responsibility as an app developer and what is being provided by those 
> libraries for me.
>
> For example, based on Clojure tutorials I have built a Compojure web 
> application that:
>
> 1. Accepts JSON from a client;
> 2. Inserts a database record based on the JSON (using the official JDBC 
> wrappers).
>
> This is implemented in the most simple way possible: the JSON map is 
> basically passed directly to the function that inserts that map in the 
> database. I don't even name database columns and I don't filter text to 
> mitigate against attacks. 
>
> In my equivalent Java web application, I'd know to white-list keys for my 
> JSON unmarshalling, I'd name explicit columns in my database operations, 
> and I'd run the submitted user text through filters to strip out any 
> malicious scripts or whatever, or escape the text when reading data back.
>
> I would have no confidence hosting this web application on the public 
> internet in its current state.
>
> Now, admittedly my Clojure experience is limited (at time of writing I 
> have about three part-time days of experience!), so these things may be 
> obvious to others here, but right now this is the sort of thing I simply 
> don't know how to do with Clojure and the third party libraries I'm using.
>
> By the way, I do use Friend already and I am finding it really useful.
>
> On Friday, 14 December 2012 17:36:57 UTC, Chas Emerick wrote:
>>
>> Some recent discussions related to my development of Friend have prompted 
>> me to create a new group: 
>>
>> https://groups.google.com/group/clojure-sec 
>> "Dedicated to discussing security issues affecting those building 
>> applications with Clojure and its variants." 
>>
>> I'm sure many of us are building applications that have security 
>> considerations.  I think it would be helpful at this point if there were a 
>> dedicated place for discussions around addressing those considerations; 
>> thus, clojure-sec. 
>>
>> We'll see what people actually want to talk about, but I'd be happy if 
>> any of these classes of topics become common: 
>>
>> * usage and design of particular security-related libraries and tools 
>> * security-related tech available in the various host environments that 
>> we can leverage from Clojure(Script/.CLR/-py/c/etc) 
>> * Clojure-specific concerns (e.g. untrusted code evaluation / jailing) 
>> * issues or weaknesses in particular Clojure implementations, libraries, 
>> etc. 
>> * discussion of more general-interest security topics that nevertheless 
>> impinge upon our work in Clojure 
>> * more, more, more 
>>
>> I'm looking forward to learning. 
>>
>> Cheers, 
>>
>> - Chas 
>>
>> -- 
>> http://cemerick.com 
>> [Clojure Programming from O'Reilly](http://www.clojurebook.com) 
>>
>>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that

Re: [ANN] clojure-sec

2013-11-18 Thread wm . mark . lee 
This list seems somewhat inactive, which I find a bit surprising, but I am 
very interested in one particular aspect of security when I build Clojure 
apps.

Right now my interest is in building REST web services and web applications 
backed by a relational database with something like Angular or Backbone at 
the front-end. I'm therefore interested in applying best practices in 
securing web applications for the public internet.

I don't have a deep background in security, but as a seasoned Java 
developer I have a good idea of some of the security considerations for web 
applications, and I agree with another post here that OWASP is a very 
useful resource. My specific interests in security are mainly mitigations 
against:

1. SQL injection;
2. Cross-site scripting;
3. Request forgery.

When it comes to the many libraries available for Clojure I struggle to 
find good information on these topics, so I'm unsure what is my 
responsibility as an app developer and what is being provided by those 
libraries for me.

For example, based on Clojure tutorials I have built a Compojure web 
application that:

1. Accepts JSON from a client;
2. Inserts a database record based on the JSON (using the official JDBC 
wrappers).

This is implemented in the most simple way possible: the JSON map is 
basically passed directly to the function that inserts that map in the 
database. I don't even name database columns and I don't filter text to 
mitigate against attacks. 

In my equivalent Java web application, I'd know to white-list keys for my 
JSON unmarshalling, I'd name explicit columns in my database operations, 
and I'd run the submitted user text through filters to strip out any 
malicious scripts or whatever, or escape the text when reading data back.

I would have no confidence hosting this web application on the public 
internet in its current state.

Now, admittedly my Clojure experience is limited (at time of writing I have 
about three part-time days of experience!), so these things may be obvious 
to others here, but right now this is the sort of thing I simply don't know 
how to do with Clojure and the third party libraries I'm using.

By the way, I do use Friend already and I am finding it really useful.

On Friday, 14 December 2012 17:36:57 UTC, Chas Emerick wrote:
>
> Some recent discussions related to my development of Friend have prompted 
> me to create a new group: 
>
> https://groups.google.com/group/clojure-sec 
> "Dedicated to discussing security issues affecting those building 
> applications with Clojure and its variants." 
>
> I'm sure many of us are building applications that have security 
> considerations.  I think it would be helpful at this point if there were a 
> dedicated place for discussions around addressing those considerations; 
> thus, clojure-sec. 
>
> We'll see what people actually want to talk about, but I'd be happy if any 
> of these classes of topics become common: 
>
> * usage and design of particular security-related libraries and tools 
> * security-related tech available in the various host environments that we 
> can leverage from Clojure(Script/.CLR/-py/c/etc) 
> * Clojure-specific concerns (e.g. untrusted code evaluation / jailing) 
> * issues or weaknesses in particular Clojure implementations, libraries, 
> etc. 
> * discussion of more general-interest security topics that nevertheless 
> impinge upon our work in Clojure 
> * more, more, more 
>
> I'm looking forward to learning. 
>
> Cheers, 
>
> - Chas 
>
> -- 
> http://cemerick.com 
> [Clojure Programming from O'Reilly](http://www.clojurebook.com) 
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] clojure-sec

2012-12-14 Thread Jonathan Irving 
Neat!

I realize this isn't exclusively web-oriented, but given Friend, I expect 
that will dominate. So, I give you OWASP:

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

There is a lot of documented and codified experience in OWASP that may be 
fruitfully extracted and hopefully contributed back in the form of Clojure 
implementations.

cheers, J

On Friday, December 14, 2012 12:36:57 PM UTC-5, Chas Emerick wrote:
>
> Some recent discussions related to my development of Friend have prompted 
> me to create a new group: 
>
> https://groups.google.com/group/clojure-sec 
> "Dedicated to discussing security issues affecting those building 
> applications with Clojure and its variants." 
>
> I'm sure many of us are building applications that have security 
> considerations.  I think it would be helpful at this point if there were a 
> dedicated place for discussions around addressing those considerations; 
> thus, clojure-sec. 
>
> We'll see what people actually want to talk about, but I'd be happy if any 
> of these classes of topics become common: 
>
> * usage and design of particular security-related libraries and tools 
> * security-related tech available in the various host environments that we 
> can leverage from Clojure(Script/.CLR/-py/c/etc) 
> * Clojure-specific concerns (e.g. untrusted code evaluation / jailing) 
> * issues or weaknesses in particular Clojure implementations, libraries, 
> etc. 
> * discussion of more general-interest security topics that nevertheless 
> impinge upon our work in Clojure 
> * more, more, more 
>
> I'm looking forward to learning. 
>
> Cheers, 
>
> - Chas 
>
> -- 
> http://cemerick.com 
> [Clojure Programming from O'Reilly](http://www.clojurebook.com) 
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

[ANN] clojure-sec

2012-12-14 Thread Chas Emerick 
Some recent discussions related to my development of Friend have prompted me to 
create a new group:

https://groups.google.com/group/clojure-sec
"Dedicated to discussing security issues affecting those building applications 
with Clojure and its variants."

I'm sure many of us are building applications that have security 
considerations.  I think it would be helpful at this point if there were a 
dedicated place for discussions around addressing those considerations; thus, 
clojure-sec.

We'll see what people actually want to talk about, but I'd be happy if any of 
these classes of topics become common:

* usage and design of particular security-related libraries and tools
* security-related tech available in the various host environments that we can 
leverage from Clojure(Script/.CLR/-py/c/etc)
* Clojure-specific concerns (e.g. untrusted code evaluation / jailing)
* issues or weaknesses in particular Clojure implementations, libraries, etc.
* discussion of more general-interest security topics that nevertheless impinge 
upon our work in Clojure
* more, more, more

I'm looking forward to learning.

Cheers,

- Chas

--
http://cemerick.com
[Clojure Programming from O'Reilly](http://www.clojurebook.com)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en