Security question: Can Django templates be used to execute arbitrary code on the server?

[jrief]

Is it safe to keep Django template strings inside a TextField of a Django 
model and allow users with staff privileges to edit them?

I'm asking because I'm unsure how safe/dangerous this could be. Would it be 
possible to abuse a built-in templatetag to execute arbitrary code on the 
server?

What are possible attack scenarios? XSS for sure, but that's always 
possible to whom you allow to publish HTML on their servers.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/13526179-50f4-45d1-953d-c272f1fb32bc%40googlegroups.com.

Re: Security Question...

[ringemup]

Ah, I see what you mean about sending things in plaintext over SSL.
You're right, that would be a lot simpler.

That said, I think I can handle the API keys with one model plus less
than a dozen lines of verification code, so it's not a huge burden.  I
just don't have a whole lot of experience devising security schemes,
so wanted to make sure the concept was fundamentally sound.  ;-)

Thanks  for all your help!


On May 25, 10:26 am, Alex Robbins 
wrote:
> Yeah, I understand that the data doesn't need to be encrypted. I just
> agree with you that SSL would be ideal.
>
> If you had SSL, then I don't think you'd need to work as hard with the
> public/private key hashing stuff. If all the transmitted data was
> encrypted (SSL) you could just send a clear-text password in the post
> data. No hashing, no public/private key, just easy.
>
> Alex
>
>
>
> On Tue, May 25, 2010 at 9:17 AM, ringemup  wrote:
>
> > By app-level solution you mean some sort of custom encryption /
> > decryption scheme for the data dictionaries?
>
> > I'm still not convinced the data needs encryption -- I mean, it
> > wouldn't hurt and in an ideal world I'd just push everything over SSL,
> > but the worst thing that happens if someone gets hold of the data
> > we're exchanging is a customer who has to call support because their
> > activation key registers as already in-use, not any sort of identity
> > theft or loss of financial credentials.
>
> > Mostly with this I'm just trying to make sure that I can prevent
> > unauthorized users from using the API to make themselves free
> > activation keys.
>
> > On May 25, 10:02 am, Alex Robbins 
> > wrote:
> >> It might be worth a try to see if the self-signed cert gets you into
> >> trouble or not. Some url libraries might complain about it, but I
> >> don't think that the behavior is universal. As I think about it, I
> >> think it is normally browsers that whine about self-signed certs.
> >> Maybe the other server wouldn't even mention it? Anyway, it'd be a lot
> >> easier to setup an ssl cert than roll your own app level solution.
>
> >> Good luck!
> >> Alex
>
> >> On May 24, 10:57 am, ringemup  wrote:
>
> >> > Not a bad idea, actually, but the other site is on shared hosting, so
> >> > I don't expect the host to be willing to add a self-signed cert as
> >> > trusted.
>
> >> > On May 24, 10:07 am, Alex Robbins 
> >> > wrote:
>
> >> > > Just a thought, but if you are the only person using the url, you
> >> > > could make your own self-signed security cert. It would be free and
> >> > > protect your data. It won't show up as trusted to users, but your
> >> > > other server can be set to accept it. (Assuming the lack of ssl is a
> >> > > budget issue, that wouldn't fix a technical issue.)
>
> >> > > Alex
>
> >> > > On May 23, 10:10 am, ringemup  wrote:
>
> >> > > > Hi folks --
>
> >> > > > I'm putting together a simple API to allow a separately-hosted but
> >> > > > trusted site to perform a very limited set of actions on my site.  
> >> > > > I'm
> >> > > > wondering whether the design I've come up with is reasonably secure:
>
> >> > > > - Other site gets an API key, which is actually in two parts, public
> >> > > > key and private key, each of which is a uuid generated by Python's
> >> > > > uuid module.
>
> >> > > > - The API key object in the DB references a User object, whose
> >> > > > permissions determine what actions the API key owner may take
>
> >> > > > - Other site submits a POST request to a special URL on my site.  
> >> > > > POST
> >> > > > request contains 3 vars: public_key, data (as JSON), hash.
>
> >> > > > - Hash is a SHA1 of the data concatenated with the private key
>
> >> > > > - I use the public key to search the database for the API key and
> >> > > > permissions.
>
> >> > > > - I generate the SHA1 of the data concatenated with the private key
> >> > > > from the DB, and check it against the submitted hash; only if they
> >> > > > match do I decode the data dict and take the actions specified within
>
> >> > > > - I then return an HTTP response containing a JSON object of the
> >> > > > format:
>
> >> > > > {
> >> > > >     return_data: [object containing success / failure codes, 
> >> > > > messages,
> >> > > > any other data],
> >> > > >     hash: [SHA1 of return_data concatenated with private key]
>
> >> > > > }
>
> >> > > > - All data will be transmitted in the clear (no SSL currently
> >> > > > available -- *sigh*), but there will be no sensitive data in the
> >> > > > incoming data dict.  return_data may contain values that aren't meant
> >> > > > to be broadcasted, but aren't really sensitive (along the lines of
> >> > > > activation keys for a game)
>
> >> > > > Do you see any major potential flaws in this plan?
>
> >> > > > Thanks!
>
> >> > > > --
> >> > > > You received this message because you are subscribed 

Re: Security Question...

[Alex Robbins]

Yeah, I understand that the data doesn't need to be encrypted. I just
agree with you that SSL would be ideal.

If you had SSL, then I don't think you'd need to work as hard with the
public/private key hashing stuff. If all the transmitted data was
encrypted (SSL) you could just send a clear-text password in the post
data. No hashing, no public/private key, just easy.

Alex



On Tue, May 25, 2010 at 9:17 AM, ringemup  wrote:
>
> By app-level solution you mean some sort of custom encryption /
> decryption scheme for the data dictionaries?
>
> I'm still not convinced the data needs encryption -- I mean, it
> wouldn't hurt and in an ideal world I'd just push everything over SSL,
> but the worst thing that happens if someone gets hold of the data
> we're exchanging is a customer who has to call support because their
> activation key registers as already in-use, not any sort of identity
> theft or loss of financial credentials.
>
> Mostly with this I'm just trying to make sure that I can prevent
> unauthorized users from using the API to make themselves free
> activation keys.
>
>
> On May 25, 10:02 am, Alex Robbins 
> wrote:
>> It might be worth a try to see if the self-signed cert gets you into
>> trouble or not. Some url libraries might complain about it, but I
>> don't think that the behavior is universal. As I think about it, I
>> think it is normally browsers that whine about self-signed certs.
>> Maybe the other server wouldn't even mention it? Anyway, it'd be a lot
>> easier to setup an ssl cert than roll your own app level solution.
>>
>> Good luck!
>> Alex
>>
>> On May 24, 10:57 am, ringemup  wrote:
>>
>>
>>
>> > Not a bad idea, actually, but the other site is on shared hosting, so
>> > I don't expect the host to be willing to add a self-signed cert as
>> > trusted.
>>
>> > On May 24, 10:07 am, Alex Robbins 
>> > wrote:
>>
>> > > Just a thought, but if you are the only person using the url, you
>> > > could make your own self-signed security cert. It would be free and
>> > > protect your data. It won't show up as trusted to users, but your
>> > > other server can be set to accept it. (Assuming the lack of ssl is a
>> > > budget issue, that wouldn't fix a technical issue.)
>>
>> > > Alex
>>
>> > > On May 23, 10:10 am, ringemup  wrote:
>>
>> > > > Hi folks --
>>
>> > > > I'm putting together a simple API to allow a separately-hosted but
>> > > > trusted site to perform a very limited set of actions on my site.  I'm
>> > > > wondering whether the design I've come up with is reasonably secure:
>>
>> > > > - Other site gets an API key, which is actually in two parts, public
>> > > > key and private key, each of which is a uuid generated by Python's
>> > > > uuid module.
>>
>> > > > - The API key object in the DB references a User object, whose
>> > > > permissions determine what actions the API key owner may take
>>
>> > > > - Other site submits a POST request to a special URL on my site.  POST
>> > > > request contains 3 vars: public_key, data (as JSON), hash.
>>
>> > > > - Hash is a SHA1 of the data concatenated with the private key
>>
>> > > > - I use the public key to search the database for the API key and
>> > > > permissions.
>>
>> > > > - I generate the SHA1 of the data concatenated with the private key
>> > > > from the DB, and check it against the submitted hash; only if they
>> > > > match do I decode the data dict and take the actions specified within
>>
>> > > > - I then return an HTTP response containing a JSON object of the
>> > > > format:
>>
>> > > > {
>> > > >     return_data: [object containing success / failure codes, messages,
>> > > > any other data],
>> > > >     hash: [SHA1 of return_data concatenated with private key]
>>
>> > > > }
>>
>> > > > - All data will be transmitted in the clear (no SSL currently
>> > > > available -- *sigh*), but there will be no sensitive data in the
>> > > > incoming data dict.  return_data may contain values that aren't meant
>> > > > to be broadcasted, but aren't really sensitive (along the lines of
>> > > > activation keys for a game)
>>
>> > > > Do you see any major potential flaws in this plan?
>>
>> > > > Thanks!
>>
>> > > > --
>> > > > You received this message because you are subscribed to the Google 
>> > > > Groups "Django users" group.
>> > > > To post to this group, send email to django-us...@googlegroups.com.
>> > > > To unsubscribe from this group, send email to 
>> > > > django-users+unsubscr...@googlegroups.com.
>> > > > For more options, visit this group 
>> > > > athttp://groups.google.com/group/django-users?hl=en.
>>
>> > > --
>> > > You received this message because you are subscribed to the Google 
>> > > Groups "Django users" group.
>> > > To post to this group, send email to django-us...@googlegroups.com.
>> > > To unsubscribe from this group, send email to 
>> > > django-users+unsubscr...@googlegroups.com.
>> 

Re: Security Question...

[ringemup]

By app-level solution you mean some sort of custom encryption /
decryption scheme for the data dictionaries?

I'm still not convinced the data needs encryption -- I mean, it
wouldn't hurt and in an ideal world I'd just push everything over SSL,
but the worst thing that happens if someone gets hold of the data
we're exchanging is a customer who has to call support because their
activation key registers as already in-use, not any sort of identity
theft or loss of financial credentials.

Mostly with this I'm just trying to make sure that I can prevent
unauthorized users from using the API to make themselves free
activation keys.


On May 25, 10:02 am, Alex Robbins 
wrote:
> It might be worth a try to see if the self-signed cert gets you into
> trouble or not. Some url libraries might complain about it, but I
> don't think that the behavior is universal. As I think about it, I
> think it is normally browsers that whine about self-signed certs.
> Maybe the other server wouldn't even mention it? Anyway, it'd be a lot
> easier to setup an ssl cert than roll your own app level solution.
>
> Good luck!
> Alex
>
> On May 24, 10:57 am, ringemup  wrote:
>
>
>
> > Not a bad idea, actually, but the other site is on shared hosting, so
> > I don't expect the host to be willing to add a self-signed cert as
> > trusted.
>
> > On May 24, 10:07 am, Alex Robbins 
> > wrote:
>
> > > Just a thought, but if you are the only person using the url, you
> > > could make your own self-signed security cert. It would be free and
> > > protect your data. It won't show up as trusted to users, but your
> > > other server can be set to accept it. (Assuming the lack of ssl is a
> > > budget issue, that wouldn't fix a technical issue.)
>
> > > Alex
>
> > > On May 23, 10:10 am, ringemup  wrote:
>
> > > > Hi folks --
>
> > > > I'm putting together a simple API to allow a separately-hosted but
> > > > trusted site to perform a very limited set of actions on my site.  I'm
> > > > wondering whether the design I've come up with is reasonably secure:
>
> > > > - Other site gets an API key, which is actually in two parts, public
> > > > key and private key, each of which is a uuid generated by Python's
> > > > uuid module.
>
> > > > - The API key object in the DB references a User object, whose
> > > > permissions determine what actions the API key owner may take
>
> > > > - Other site submits a POST request to a special URL on my site.  POST
> > > > request contains 3 vars: public_key, data (as JSON), hash.
>
> > > > - Hash is a SHA1 of the data concatenated with the private key
>
> > > > - I use the public key to search the database for the API key and
> > > > permissions.
>
> > > > - I generate the SHA1 of the data concatenated with the private key
> > > > from the DB, and check it against the submitted hash; only if they
> > > > match do I decode the data dict and take the actions specified within
>
> > > > - I then return an HTTP response containing a JSON object of the
> > > > format:
>
> > > > {
> > > >     return_data: [object containing success / failure codes, messages,
> > > > any other data],
> > > >     hash: [SHA1 of return_data concatenated with private key]
>
> > > > }
>
> > > > - All data will be transmitted in the clear (no SSL currently
> > > > available -- *sigh*), but there will be no sensitive data in the
> > > > incoming data dict.  return_data may contain values that aren't meant
> > > > to be broadcasted, but aren't really sensitive (along the lines of
> > > > activation keys for a game)
>
> > > > Do you see any major potential flaws in this plan?
>
> > > > Thanks!
>
> > > > --
> > > > You received this message because you are subscribed to the Google 
> > > > Groups "Django users" group.
> > > > To post to this group, send email to django-us...@googlegroups.com.
> > > > To unsubscribe from this group, send email to 
> > > > django-users+unsubscr...@googlegroups.com.
> > > > For more options, visit this group 
> > > > athttp://groups.google.com/group/django-users?hl=en.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups 
> > > "Django users" group.
> > > To post to this group, send email to django-us...@googlegroups.com.
> > > To unsubscribe from this group, send email to 
> > > django-users+unsubscr...@googlegroups.com.
> > > For more options, visit this group 
> > > athttp://groups.google.com/group/django-users?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django users" group.
> > To post to this group, send email to django-us...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-users?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups 
> 

Re: Security Question...

[Alex Robbins]

It might be worth a try to see if the self-signed cert gets you into
trouble or not. Some url libraries might complain about it, but I
don't think that the behavior is universal. As I think about it, I
think it is normally browsers that whine about self-signed certs.
Maybe the other server wouldn't even mention it? Anyway, it'd be a lot
easier to setup an ssl cert than roll your own app level solution.

Good luck!
Alex

On May 24, 10:57 am, ringemup  wrote:
> Not a bad idea, actually, but the other site is on shared hosting, so
> I don't expect the host to be willing to add a self-signed cert as
> trusted.
>
> On May 24, 10:07 am, Alex Robbins 
> wrote:
>
>
>
> > Just a thought, but if you are the only person using the url, you
> > could make your own self-signed security cert. It would be free and
> > protect your data. It won't show up as trusted to users, but your
> > other server can be set to accept it. (Assuming the lack of ssl is a
> > budget issue, that wouldn't fix a technical issue.)
>
> > Alex
>
> > On May 23, 10:10 am, ringemup  wrote:
>
> > > Hi folks --
>
> > > I'm putting together a simple API to allow a separately-hosted but
> > > trusted site to perform a very limited set of actions on my site.  I'm
> > > wondering whether the design I've come up with is reasonably secure:
>
> > > - Other site gets an API key, which is actually in two parts, public
> > > key and private key, each of which is a uuid generated by Python's
> > > uuid module.
>
> > > - The API key object in the DB references a User object, whose
> > > permissions determine what actions the API key owner may take
>
> > > - Other site submits a POST request to a special URL on my site.  POST
> > > request contains 3 vars: public_key, data (as JSON), hash.
>
> > > - Hash is a SHA1 of the data concatenated with the private key
>
> > > - I use the public key to search the database for the API key and
> > > permissions.
>
> > > - I generate the SHA1 of the data concatenated with the private key
> > > from the DB, and check it against the submitted hash; only if they
> > > match do I decode the data dict and take the actions specified within
>
> > > - I then return an HTTP response containing a JSON object of the
> > > format:
>
> > > {
> > >     return_data: [object containing success / failure codes, messages,
> > > any other data],
> > >     hash: [SHA1 of return_data concatenated with private key]
>
> > > }
>
> > > - All data will be transmitted in the clear (no SSL currently
> > > available -- *sigh*), but there will be no sensitive data in the
> > > incoming data dict.  return_data may contain values that aren't meant
> > > to be broadcasted, but aren't really sensitive (along the lines of
> > > activation keys for a game)
>
> > > Do you see any major potential flaws in this plan?
>
> > > Thanks!
>
> > > --
> > > You received this message because you are subscribed to the Google Groups 
> > > "Django users" group.
> > > To post to this group, send email to django-us...@googlegroups.com.
> > > To unsubscribe from this group, send email to 
> > > django-users+unsubscr...@googlegroups.com.
> > > For more options, visit this group 
> > > athttp://groups.google.com/group/django-users?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django users" group.
> > To post to this group, send email to django-us...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-users?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Security Question...

[ringemup]

Not a bad idea, actually, but the other site is on shared hosting, so
I don't expect the host to be willing to add a self-signed cert as
trusted.



On May 24, 10:07 am, Alex Robbins 
wrote:
> Just a thought, but if you are the only person using the url, you
> could make your own self-signed security cert. It would be free and
> protect your data. It won't show up as trusted to users, but your
> other server can be set to accept it. (Assuming the lack of ssl is a
> budget issue, that wouldn't fix a technical issue.)
>
> Alex
>
> On May 23, 10:10 am, ringemup  wrote:
>
>
>
> > Hi folks --
>
> > I'm putting together a simple API to allow a separately-hosted but
> > trusted site to perform a very limited set of actions on my site.  I'm
> > wondering whether the design I've come up with is reasonably secure:
>
> > - Other site gets an API key, which is actually in two parts, public
> > key and private key, each of which is a uuid generated by Python's
> > uuid module.
>
> > - The API key object in the DB references a User object, whose
> > permissions determine what actions the API key owner may take
>
> > - Other site submits a POST request to a special URL on my site.  POST
> > request contains 3 vars: public_key, data (as JSON), hash.
>
> > - Hash is a SHA1 of the data concatenated with the private key
>
> > - I use the public key to search the database for the API key and
> > permissions.
>
> > - I generate the SHA1 of the data concatenated with the private key
> > from the DB, and check it against the submitted hash; only if they
> > match do I decode the data dict and take the actions specified within
>
> > - I then return an HTTP response containing a JSON object of the
> > format:
>
> > {
> >     return_data: [object containing success / failure codes, messages,
> > any other data],
> >     hash: [SHA1 of return_data concatenated with private key]
>
> > }
>
> > - All data will be transmitted in the clear (no SSL currently
> > available -- *sigh*), but there will be no sensitive data in the
> > incoming data dict.  return_data may contain values that aren't meant
> > to be broadcasted, but aren't really sensitive (along the lines of
> > activation keys for a game)
>
> > Do you see any major potential flaws in this plan?
>
> > Thanks!
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django users" group.
> > To post to this group, send email to django-us...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-users?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Security Question...

[Alex Robbins]

Just a thought, but if you are the only person using the url, you
could make your own self-signed security cert. It would be free and
protect your data. It won't show up as trusted to users, but your
other server can be set to accept it. (Assuming the lack of ssl is a
budget issue, that wouldn't fix a technical issue.)

Alex

On May 23, 10:10 am, ringemup  wrote:
> Hi folks --
>
> I'm putting together a simple API to allow a separately-hosted but
> trusted site to perform a very limited set of actions on my site.  I'm
> wondering whether the design I've come up with is reasonably secure:
>
> - Other site gets an API key, which is actually in two parts, public
> key and private key, each of which is a uuid generated by Python's
> uuid module.
>
> - The API key object in the DB references a User object, whose
> permissions determine what actions the API key owner may take
>
> - Other site submits a POST request to a special URL on my site.  POST
> request contains 3 vars: public_key, data (as JSON), hash.
>
> - Hash is a SHA1 of the data concatenated with the private key
>
> - I use the public key to search the database for the API key and
> permissions.
>
> - I generate the SHA1 of the data concatenated with the private key
> from the DB, and check it against the submitted hash; only if they
> match do I decode the data dict and take the actions specified within
>
> - I then return an HTTP response containing a JSON object of the
> format:
>
> {
>     return_data: [object containing success / failure codes, messages,
> any other data],
>     hash: [SHA1 of return_data concatenated with private key]
>
> }
>
> - All data will be transmitted in the clear (no SSL currently
> available -- *sigh*), but there will be no sensitive data in the
> incoming data dict.  return_data may contain values that aren't meant
> to be broadcasted, but aren't really sensitive (along the lines of
> activation keys for a game)
>
> Do you see any major potential flaws in this plan?
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Security Question...

[ringemup]

Hi folks --

I'm putting together a simple API to allow a separately-hosted but
trusted site to perform a very limited set of actions on my site.  I'm
wondering whether the design I've come up with is reasonably secure:

- Other site gets an API key, which is actually in two parts, public
key and private key, each of which is a uuid generated by Python's
uuid module.

- The API key object in the DB references a User object, whose
permissions determine what actions the API key owner may take

- Other site submits a POST request to a special URL on my site.  POST
request contains 3 vars: public_key, data (as JSON), hash.

- Hash is a SHA1 of the data concatenated with the private key

- I use the public key to search the database for the API key and
permissions.

- I generate the SHA1 of the data concatenated with the private key
from the DB, and check it against the submitted hash; only if they
match do I decode the data dict and take the actions specified within

- I then return an HTTP response containing a JSON object of the
format:

{
return_data: [object containing success / failure codes, messages,
any other data],
hash: [SHA1 of return_data concatenated with private key]
}

- All data will be transmitted in the clear (no SSL currently
available -- *sigh*), but there will be no sensitive data in the
incoming data dict.  return_data may contain values that aren't meant
to be broadcasted, but aren't really sensitive (along the lines of
activation keys for a game)

Do you see any major potential flaws in this plan?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Security question

[Gerard Petersen]

Hi Oliver,

This feels completely off topic for a Django post, nevertheless ..

I don't see the problem. If your webserver contacts the application server via 
port 80 or 443 then you should have your firewall between DMZ 1 and 2 allow 
those ports. And allow only the source IP of the webserver to do that.

For more control you could limit request bursts in your firewall, but then you 
should really know what your doing. As far as mac addresses, everything is 
spoofable these days so monitoring logs from in host firewalls (iptables) is 
always a good idea.

I don't see how this is a Django issue. Don't know if this helped, maybe you 
should drop a post at: http://lists.netfilter.org/


Regards,

Gerard.


OliverMarchand wrote:
> Dear all,
> 
> we are using Django as an application server. Now we want our website
> server to be able to read from (and eventually write to) that
> application server. Now the security question arises. The proposal is
> to have
> - the webserver in a DMZ 1
> - the Django application server in a DMZ 2
> - our internal LAN as another network
> Then we allow very limited requests from DMZ 1 into DMZ 2 and
> to allow no access from DMZ 2 into the LAN.
> 
> Are there people here with similar setup or views on the subject.
> So you have suggestions about the best limitation for requests from
> DMZ 1 to DMZ 2 (based on port,MAC adress, etc...)?
> 
> Thanks for any advice,
> Oliver
> > 

-- 
urls = { 'fun':  'www.zonderbroodje.nl',  'tech':  'www.gp-net.nl' }


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Security question

[OliverMarchand]

Dear all,

we are using Django as an application server. Now we want our website
server to be able to read from (and eventually write to) that
application server. Now the security question arises. The proposal is
to have
- the webserver in a DMZ 1
- the Django application server in a DMZ 2
- our internal LAN as another network
Then we allow very limited requests from DMZ 1 into DMZ 2 and
to allow no access from DMZ 2 into the LAN.

Are there people here with similar setup or views on the subject.
So you have suggestions about the best limitation for requests from
DMZ 1 to DMZ 2 (based on port,MAC adress, etc...)?

Thanks for any advice,
Oliver
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---