[Owasp-delhi] Owasp-delhi Digest, Vol 18, Issue 18

Abhishek Arora abhishekarora01 at gmail.com
Tue Jan 20 11:18:06 EST 2009


I am a first year student at Delhi College of Engineering and have recently
been learning PHP. I was wondering if there is any way to implement an SQL
Injection even when we have addslashes included in the code.
I also came across the concept of Rainbow tables. Does this make MD5 hashing
of small (in length) values irrelevant?

I also wanted to know if I am eligible to attend OWASP meetings.

Thank You
Abhishek Arora

2009/1/20 <owasp-delhi-request at lists.owasp.org>

> Send Owasp-delhi mailing list submissions to
>        owasp-delhi at lists.owasp.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.owasp.org/mailman/listinfo/owasp-delhi
> or, via email, send a message with subject or body 'help' to
>        owasp-delhi-request at lists.owasp.org
>
> You can reach the person managing the list at
>        owasp-delhi-owner at lists.owasp.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Owasp-delhi digest..."
>
>
> Today's Topics:
>
>   1. Re: SSL Broken.. (Gunwant Singh)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 19 Jan 2009 23:25:39 +0530
> From: "Gunwant Singh" <gunwant.s at gmail.com>
> Subject: Re: [Owasp-delhi] SSL Broken..
> To: lavakumar.kuppan at rbs.com
> Cc: owasp-delhi at lists.owasp.org
> Message-ID:
>        <44b2bd060901190955j11774427j2cc832d1e782267a at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Lava,
>
> Nice to see your reply. Please see my thoughts on your comments.
>
> >Now in the solution that you have suggested, the server has to fetch the
> user's password for each request which defeats the whole purpose of
> maintaning session IDs.
>
> Good point. My suggestion on this: Access the password only once and store
> it in a temporary variable securely for further transactions and then
> delete
> it as the session ends.
>
> >Ironically you had already suggested a solution and then asked the
> question, wonder if you were just checking if everyone understood your talk
> properly ;)
>
> If you would have read this mailing thread from the very scratch, you would
> have known that this question ain't related to salted MD5. I was not
> checking if people understood my talks properly. I could have done that
> there and then only.
>
> >For your salted-hashning technique or the new techique there is to be a
> lot
> of client side JS code which has to create the salted hash and send it to
> the server. The attacker would just intercept this message and replace your
> JS with another JS which does every thing like the original JS but in
> addition steals the user's clear text password and appends to the request
> which the attacker can now get by viewing your request.
>
> I would like to comment about the salted hashing part in a different e-mail
> (if I get some time) as this topic is not what I am talking about here.
> About the technique, in case if you can manipulate the generated hash
> somehow by intercepting, and make up your own hash, can you still be a part
> of the same session. I don't think so. Let me know if you can. Check out
> the
> way I told about its workings.
>
> Could you come up with some *PoC* to what you said? You said intercepting
> and manipulating the traffic on the fly travelling from the server to the
> client or the other way around? How would you do that sitting somewhere on
> the network? I am curious to know.
>
> I don't know why you guys keep involving SSL with this thing.
>
> Thanks for your feedback.
>
> -Gunwant
>
> On Mon, Jan 19, 2009 at 1:04 PM, <lavakumar.kuppan at rbs.com> wrote:
>
> >
> > Hi Gunwant,
> >
> > Thanks for bringing up this topic, can see that it has tickled quite a
> few
> > brains in the list already ;), prompting some really intelligent ideas
> and
> > arguments.
> > I was on vacations and missed out on all the fun here, but its never too
> > late so here is my humble opinion.
> >
> > There are two very important factors that have to be considered here:
> >
> > 1) Why is a session ID required.
> > 2) What is the possibilty of some one with sniffing capability to
> intercept
> > and manipulate the traffic.
> >
> >
> > 1) Why is a session ID required
> >  I believe sessiond IDs are used to avoid connecting to the DB each time
> > and validating the user's password, they are used to improve efficiency.
> > Now in the solution that you have suggested, the server has to fetch the
> > user's password for each request which defeats the whole purpose of
> > maintaning session IDs.
> > Since we are anyway reffering to the password for each request, I would
> > like to think that we can authenticate for each request with the
> salted-hash
> > technique you suggested in your december OWASP talk, provided once a salt
> is
> > used the server discards it and issues a new one.
> > Ironically you had already suggested a solution and then asked the
> > question, wonder if you were just checking if everyone understood your
> talk
> > properly ;)
> >
> > 2) What is the possibilty of some one with sniffing capability to
> intercept
> > and manipulate the traffic.
> > As someone who has done quite a bit of sniffing on customer networks
> during
> > pentests, I think that someone who is capable of sniffing would in all
> > probability also be capable of intercepting and manipulating the traffic
> > between the client and server. There might be exceptions but they would
> be
> > uncommon.
> > Any techniquie which enforces some trust on the client-side logic now
> gets
> > defeated.
> > For your salted-hashning technique or the new techique there is to be a
> lot
> > of client side JS code which has to create the salted hash and send it to
> > the server. The attacker would just intercept this message and replace
> your
> > JS with another JS which does every thing like the original JS but in
> > addition steals the user's clear text password and appends to the request
> > which the attacker can now get by viewing your request.
> > Once this happens the entitre security system is defeated as its so
> closely
> > attached to the user's password.
> > So in my opinion once someone is able to intercept a clear-text traffic
> he
> > could directly or indirectly bypass most restictions enforced.
> >
> > The thing that differentiates SSL from the suggested approach is the use
> of
> > Server certificates which establishes authenticity, unless we can figure
> out
> > a way to do that our confidentiality and integrity solutions might fail.
> >
> > Dont cosider thick client approach like java applets as reverse
> engineering
> > is a possibility.
> >
> > PS: OK, I have not suggested any solution,  am a pentester what do you
> > expect :P
> >
> > Thanks and Regards,
> > Lavakumar K
> > Penetration Tester - Global ISA
> >
> >
> >  *"Gunwant Singh" <gunwant.s at gmail.com>*
> > Sent by: owasp-delhi-bounces at lists.owasp.org
> >
> > 01/16/2009 11:06 PM
> >   To
> > owasp-delhi at lists.owasp.org
> >  cc
> >   Subject
> > Re: [Owasp-delhi] SSL Broken..
> >
> >
> >
> >
> > Hi,
> >
> > Ok, let me elucidate the workings of the technique I was talking about.
> >
> >
> > But before that I just want to shed some light on a few things so no-one
> > comes again questioning to me about these and start some endless
> argument.
> >
> > - The e-commerce site I was talking about, I never said that they are
> only
> > using the technique I am going to discuss. They might be using other
> > techniques for their protection. What I meant was I've not seen/heard
> anyone
> > else using this technique. That doesn't mean that they are only using
> this
> > technique for their protection. Every giant incorporates multi-tier
> security
> > for their resources.  I am not sure what exactly they are using besides
> this
> > technique as Nobody reveals that.  I questioned someone on a forum, he
> came
> > up with this technique, I studied, checked this on their documentation
> page,
> > discussed with some people, discussed with some more, argued with even
> more
> > and now I am here. I am looking for some feedback from you all. Just let
> me
> > know what ever you think is wrong with this. Anyhow the question is not
> that
> > whether they are using it or not but the question is 'How good is the
> > technique?'
> >
> > - Please don't misinterpret my statement. I am not saying 'Don't use
> SSL'.
> > SSL is definitely a protection mechanism for "Now" if we use it
> > appropriately (CA signed certificate with a well-tested, well-reviewed
> > implementation). Use SSL till someone finds some exploit *practically*
> not
> > theoretically. This whole discussion is based on a research question so
> I/we
> > can get a *feasible* working solution for this (may-be-a-future) problem.
> If
> > you are not interested in discussing please do not comment. And please do
> > not envisage what I am not saying.
> >
> > So here is how it works.
> >
> > No SSL. All traffic in clear text.
> > Initially we need to communicate an OOB password/code/nonce (whatever you
> > call it) to the client - only *once* not each time.
> >
> >
> > 1. The client initiates a connection request to the server. As a result,
> > server will initiate a handshake process to synchronize the time-stamps
> > between the client and itself. Then the server will analyze tolerance
> time
> > of packets leaving the client workstation till it reaches the server. The
> > tolerance time is configured so to manage slow hosts or slow traffic. In
> > plain words, server synchronizes date and time (in seconds, milliseconds
> or
> > even nanoseconds based on the criticality of the application) with the
> > client.
> >
> > 2. At the client side: the message, instantaneous time-stamp and the
> > password are concatenated and hashed via SHA-1/SHA-256, whatever one
> wishes.
> > This ensuing hash is combined with the username to form an authentication
> > header and sent to the server.
> >
> > 3. At the server side, the server sees the username and perceives which
> > user is trying to authenticate. Based on the tolerance configured
> initially
> > at the handshake time, it picks the time-stamp from its own clock and
> using
> > the password and the message it generates the hash in the same way as it
> was
> > done at the client side.
> >
> > 4. If the hash matches it generates a Session ID and maps it to the
> > username of the user. This Session ID will be sent from the client to the
> > server along with the computed hash (which is different for each request
> -
> > see next Step)
> >
> > 5. Now if the client sends another request, it appends and then hashes
> the
> > message, password and the time-stamp (which will be apparently because of
> > the different instantaneous time-stamp i.e. date and time). This
> resulting
> > string is sent to the server along with the Session ID assigned to the
> user
> > earlier. The resulting string contains a different hash as the time has
> > changed. This will be validated at the server the same way as in Step 3.
> >
> > Now how can an adversary exploit this scenario? What I think of are two
> > ways:
> >
> > 1. Either he will capture one of the hashes and try to predict the next
> > hash by brute forcing different time-stamps.
> >
> > - But this can not be possible. He doesn't have the password to generate
> > the hash.
> >
> > 2. What if he captures a series of requests and responses and replays
> them
> > back to the server at a later stage.
> >
> > - This can't be possible either. In order to interact with the server,
> one
> > needs to handshake so to synchronize itself with the server's clock. The
> > attacker would not be able to synchronize because he would not be able to
> > synchronize the *past-timestamp* (in the captured traffic) with the
> server's
> > current time.
> >
> > 3. Lastly for the newbies, what if he captures the Session ID.
> >
> > - But he would not be able to produce the matching Hash for the request,
> so
> > no luck.
> >
> > A few things to contemplate:
> >
> > 1. This will be considerably be CPU intensive but can be acknowledged if
> > compared to the processing cycles SSL takes.
> >
> > 2. Time synchronization can be complex. I have no idea how to do that.
> >
> > 3. Please provide your
> > feedback/fury/antagonism/annoyance/appreciation/whatever. Hope I
> explained
> > this in a very straightforward way.
> >
> > Thanks.
> >
> > Gunwant
> >
> >
> >
> >
> >
> > On Fri, Jan 16, 2009 at 4:26 AM, Plash Chowdhary <*
> plash.chowdhary at tcs.com
> > * <plash.chowdhary at tcs.com>> wrote:
> >
> > Gunwant,
> >
> > I will be interested to know kind of soltutions are being used.
> > SInce you are talking about **Time stamp**(in clear text will be
> > perdictable, specially if a client side algo is being used) <some random
> > number in hidden field with every request,<unique captcha with every
> request
> > (this will be interesting)  can be a case but they will be not as roboust
> >  as out of band..
> > some how with Time stamps only thing that rings bell is CRYPTOGRAPHY *: D
> > *(PKI??)
> >
> > I will be really surprized if that organization is not using SSL from a
> > Vendor. (as you said its an e commerce site)
> >
> > and anyways i wont be using HTTPS on public content of my site and will
> > switch to HTTPS session only when needed (IDEALLY)
> >
> >
> > lemme know your thoughts
> >
> > Regards
> > Plash
> >
> >
> >
> >
> >   *"Gunwant Singh" <**gunwant.s at gmail.com* <gunwant.s at gmail.com>*>*
> >
> > 01/15/2009 12:30 PM
> >
> >   To
> > "Plash Chowdhary" <*plash.chowdhary at tcs.com* <plash.chowdhary at tcs.com>>
> > cc
> > *owasp-delhi at lists.owasp.org* <owasp-delhi at lists.owasp.org>  Subject
> > Re: [Owasp-delhi] SSL Broken..
> >
> >
> >
> >
> >
> >
> > Plash,
> >
> > Thanks for the idea. Please don't take my talks as overstatements, I just
> > wanted to have some innovative ideas from you guys.
> >
> > Many organizations implement session mechanisms without using SSL. As a
> > matter of fact these are not the conditions that I have set. There are
> many
> > scenarios where using SSL is unworkable and in order to provide
> protection,
> > there are solutions.
> >
> > Also, it becomes more relevant when people are trying to prove the
> > weaknesses of SSL. Not to forget, facts say that most organizations who
> use
> > SSL, use self signed certificates rather than a CA sign it.
> >
> > For sessions on non-SSL, there are many undocumented solutions which can
> be
> > put into practice but such solutions needs to be well-reviewed and
> > well-tested before they are implemented. I have come to know about one of
> > the methods implemented by one of the top e-commerce portal giants. This
> > solution is a bit tough to understand and subsequently implement it.
> Before
> > I discuss it on the mailing list, I need to make sure that I understand
> it
> > well. The only thing I can share at the moment is, it uses time-stamps.
> > Hopefully, I would be discussing this proposition in detail in the
> upcoming
> > Delhi Chapter meeting this month.
> >
> > Sorry if my talks were exaggerated. I still seek more ideas on the same
> > question if someone is willing to share.
> >
> > Many thanks.
> >
> > On Thu, Jan 15, 2009 at 11:29 PM, Plash Chowdhary <
> > *plash.chowdhary at tcs.com* <plash.chowdhary at tcs.com>> wrote:
> >
> > Gunwant,,
> >
> > Yes impractical "Off band validation" for each request in the conditions
> > you have set. Now either you come up with a solution or im implimenting
> SSL
> > *: )*
> >
> >
> > Regards
> > Plash
> >   *"Gunwant Singh" <**gunwant.s at gmail.com* <gunwant.s at gmail.com>*>*
> >
> > 01/15/2009 10:27 AM
> >
> >   To
> > "Plash Chowdhary" <*plash.chowdhary at tcs.com* <plash.chowdhary at tcs.com>>
> >  cc
> > *owasp-delhi at lists.owasp.org* <owasp-delhi at lists.owasp.org>  Subject
> > Re: [Owasp-delhi] SSL Broken..
> >
> >
> >
> >
> >
> >
> >
> >
> > I would happily accept what you say if you say how it protects.
> >
> > Tell me **how** would a sniffer miss your validation code on an
> > unencrypted channel. We should talk about mitigating not minimizing.
> >
> > Oh ! unless you are saying, a different off band validation code is sent
> > for **each** request - then it is possible but it is impractical even in
> > high risk applications.
> >
> > On Thu, Jan 15, 2009 at 9:41 PM, Plash Chowdhary <
> > *plash.chowdhary at tcs.com* <plash.chowdhary at tcs.com>> wrote:
> >
> > It does Gunwant, Use long one time off band validation....and keep a
> short
> > TTL it will minimize the risk of relpay,....
> >
> >   *"Gunwant Singh" <**gunwant.s at gmail.com* <gunwant.s at gmail.com>*>*
> >
> > 01/15/2009 09:25 AM
> >
> >   To
> > "Plash Chowdhary" <*plash.chowdhary at tcs.com* <plash.chowdhary at tcs.com>>
> >  cc
> > *owasp-delhi at lists.owasp.org* <owasp-delhi at lists.owasp.org>  Subject
> > Re: [Owasp-delhi] SSL Broken..
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > That doesn't affirm protection against replay attack, dude!
> > In the transit, anyone can see your validation code...
> > Even if you hash/encrypt it, still it can used to replay the traffic...
> > this is vulnerable.. :)
> >
> > On Thu, Jan 15, 2009 at 3:46 AM, Plash Chowdhary <
> > *plash.chowdhary at tcs.com* <plash.chowdhary at tcs.com>> wrote:
> >
> > verify user offline.. send an sms(or similar) with a validation code(long
> > randomly genrated  string) to the user everytime he logs in to validate
> and
> > use it everytime a transaction (high risk) is done or role is  changed..
> > best way still will be to use it over SSL and use digital signatures
> >
> >
> > Regards
> > Plash
> >   *"Gunwant Singh" <**gunwant.s at gmail.com* <gunwant.s at gmail.com>
> > *>*
> > Sent by: *owasp-delhi-bounces at lists.owasp.org*<
> owasp-delhi-bounces at lists.owasp.org>
> >
> > 01/14/2009 10:13 AM
> >
> >   To
> > "Karthik Muthukrishnan" <*karthik.muthukrishnan at tcs.com*<
> karthik.muthukrishnan at tcs.com>
> > >
> >  cc
> > *owasp-delhi at lists.owasp.org* <owasp-delhi at lists.owasp.org>  Subject
> > Re: [Owasp-delhi] SSL Broken..
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi,
> >
> > Thanks for your reply but that did not answer my question. You are
> telling
> > me what I can use for protecting the credentials. I know what I can use,
> but
> > just out of curiousity I want to know if I don't use SSL/VPN or any other
> > network based protection, what else can be done on the application layer
> in
> > order to protect the credentials
> > . Please see the answers below.
> >
> >
> > On Wed, Jan 14, 2009 at 3:50 PM, Karthik Muthukrishnan <*
> > karthik.muthukrishnan at tcs.com* <karthik.muthukrishnan at tcs.com>> wrote:
> >
> > > salted MD5 hashing protects the authentication credentials rightly from
> > eavesdropping on the network.
> > Salting is used to protect MD5 hashes from rainbow table attacks.
> > Apparently Yes, although ultimately it protects authentication
> credentials
> > only. Facts say the highest risk is eavesdropping if the session is
> > unencrypted.
> >
> > > SSL does the same thing.
> > Yes, SSL is used to ensure confidentiality and trust in the network
> > communiation. Confidentiality (or prevention of network eavesdropping) is
> > ensured by encryption. Trust is accomplished by Server and/or client
> > certificates.
> > I know what SSL does, but my question is something else.
> >
> > > However, in some scenarios SSL might not be feasible. For example,
> > causing heavy load on the server or may be some applications don't
> support
> > it, etc.
> > In such cases SSL Accelerators are used. They are devices which can be
> fit
> > into the architecture without changing the application or affecting the
> load
> > on the application server.
> >
> > Again my question is something else. I know if SSL doesn't work,
> > accelerators help expedite the processing. What I want to know is, if I
> "Do
> > Not" want to use SSL what measures can be taken.
> >
> >
> > > We can protect the authentication credentials using salted MD5 hashing
> > or by using SSL.
> > To protect authentication credentials in HTTP, we have to rely on SSL.
> > Hashes are a secure (aka not in clear text) way to store authentication
> > credentials.
> > So you are proclaiming that we *have to* rely  on SSL- no other
> > alternative.
> > Hashes are also used in many applications for many different purposes
> > besides authenticity and integrity.
> >
> >
> > > In order to protect the Session credentials (Session ID, tokens,
> > cookies, etc) on a non-SSL channel what measures can be taken?
> > To protect either auth or session credentials we have to ensure
> > confidentiality of the communication channel. If we dont use HTTPS, then
> VPN
> > might be another option. While authentication credentials can be
> protected
> > by some challenge handshake mechanism (similar to CHAP), we would need to
> > protect session creds by encrypting the channel.
> > I was asking that if we can provide some protection on the application
> > level rather than on the network level. Besides SSL/VPN there are many
> > options available for protecting the authentication credentials. I want
> to
> > know (just out of curiousity) that how can we secure the session
> credentials
> > on an unencrypted/non-SSL channel. I know this will take too much
> processing
> > cycles, time synchronization, quantization in milliseconds even
> nanoseconds,
> > affirmation of the key exchange, dynamic hashing key generation to
> mitigate
> > replay attacks, and even more.
> >
> > I just want to know  if anyone has an idea on how it can be done if h/she
> > is willing to share that would be really appreciative. Please make sure
> > you understand what I am looking for.
> > No offence :)
> >
> >
> >
> > Karthik
> > =====-----=====-----=====
> > Notice: The information contained in this e-mail
> > message and/or attachments to it may contain
> > confidential or privileged information. If you are
> > not the intended recipient, any dissemination, use,
> > review, distribution, printing or copying of the
> > information contained in this e-mail message
> > and/or attachments to it are strictly prohibited. If
> > you have received this communication in error,
> > please notify us by reply e-mail or telephone and
> > immediately and permanently delete the message
> > and any attachments. Thank you
> >
> >
> >
> >
> >
> >
> > --
> > Gunwant Singh
> > _______________________________________________
> > Owasp-delhi mailing list*
> > **Owasp-delhi at lists.owasp.org* <Owasp-delhi at lists.owasp.org>*
> > *
> > *https://lists.owasp.org/mailman/listinfo/owasp-delhi*<
> https://lists.owasp.org/mailman/listinfo/owasp-delhi>
> >
> > ForwardSourceID:NT00005236
> > =====-----=====-----=====
> > Notice: The information contained in this e-mail
> > message and/or attachments to it may contain
> > confidential or privileged information. If you are
> > not the intended recipient, any dissemination, use,
> > review, distribution, printing or copying of the
> > information contained in this e-mail message
> > and/or attachments to it are strictly prohibited. If
> > you have received this communication in error,
> > please notify us by reply e-mail or telephone and
> > immediately and permanently delete the message
> > and any attachments. Thank you
> >
> >
> >
> >
> >
> >
> > --
> > Gunwant Singh
> >
> > ForwardSourceID:NT000052F2
> >
> > =====-----=====-----=====
> > Notice: The information contained in this e-mail
> > message and/or attachments to it may contain
> > confidential or privileged information. If you are
> > not the intended recipient, any dissemination, use,
> > review, distribution, printing or copying of the
> > information contained in this e-mail message
> > and/or attachments to it are strictly prohibited. If
> > you have received this communication in error,
> > please notify us by reply e-mail or telephone and
> > immediately and permanently delete the message
> > and any attachments. Thank you
> >
> >
> >
> >
> >
> >
> > --
> > Gunwant Singh
> >
> > ForwardSourceID:NT0000530E
> >
> > =====-----=====-----=====
> > Notice: The information contained in this e-mail
> > message and/or attachments to it may contain
> > confidential or privileged information. If you are
> > not the intended recipient, any dissemination, use,
> > review, distribution, printing or copying of the
> > information contained in this e-mail message
> > and/or attachments to it are strictly prohibited. If
> > you have received this communication in error,
> > please notify us by reply e-mail or telephone and
> > immediately and permanently delete the message
> > and any attachments. Thank you
> >
> >
> >
> >
> >
> >
> > --
> > Gunwant Singh
> >
> > ForwardSourceID:NT0000533A
> > =====-----=====-----=====
> > Notice: The information contained in this e-mail
> > message and/or attachments to it may contain
> > confidential or privileged information. If you are
> > not the intended recipient, any dissemination, use,
> > review, distribution, printing or copying of the
> > information contained in this e-mail message
> > and/or attachments to it are strictly prohibited. If
> > you have received this communication in error,
> > please notify us by reply e-mail or telephone and
> > immediately and permanently delete the message
> > and any attachments. Thank you
> >
> >
> >
> >
> >
> >
> > --
> > Gunwant Singh
> >
> >
> >
> >
> > --
> > Gunwant Singh
> > _______________________________________________
> > Owasp-delhi mailing list
> > Owasp-delhi at lists.owasp.org
> > https://lists.owasp.org/mailman/listinfo/owasp-delhi
> >
> >
> > This message (including any attachments) is confidential and may be
> > privileged. If you have received it by mistake please notify the sender
> by
> > return e-mail and delete this message from your system. Any unauthorised
> use
> > or dissemination of this message in whole or in part is strictly
> prohibited.
> > Please note that e-mails are susceptible to change. ABN AMRO Central
> > Enterprise Services Pvt Ltd, part of RBS Group plc , having its
> registered
> > office at Empire Complex, 414 Senapati Bapat Marg, Lower Parel (W),
> Mumbai -
> > 400 013 , including its group companies, shall not be liable for the
> > improper or incomplete transmission of the information contained in this
> > communication nor for any delay in its receipt or damage to your system.
> ABN
> > AMRO Central Enterprise Services Pvt Ltd (or its group companies) does
> not
> > guarantee that the integrity of this communication has been maintained
> nor
> > that this communication is free of viruses, interceptions or
> interference.
> >
> > ______________________________________________________________________
> > This email has been scanned by the MessageLabs Email Security System.
> > For more information please visit http://www.messagelabs.com/email
> > ______________________________________________________________________
> >
>
>
>
> --
> Gunwant Singh
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> https://lists.owasp.org/pipermail/owasp-delhi/attachments/20090119/bd580bc5/attachment.html
>
> ------------------------------
>
> _______________________________________________
> Owasp-delhi mailing list
> Owasp-delhi at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-delhi
>
>
> End of Owasp-delhi Digest, Vol 18, Issue 18
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-delhi/attachments/20090120/4226c9c4/attachment-0001.html 


More information about the Owasp-delhi mailing list