Re: [OT] Sessions mix-up on Tomcat 6.0.26 on Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yawar, On 8/21/2010 12:42 AM, Yawar Khan wrote: chris, i had a look at container managed authentication and its quite handy. but i couldnt see how i can add extra functionality like calling an encryption function on password text field before tomcat does its authentication on it. It's built-in. As long as you just want to do a simple hash of the user's password (like MD5, SHA-256, etc.), you should be good to go. Unfortunately, Tomcat does not currently support any salting of the password before hashing. for js, my client side authentication is done on form submit button click event, if the hackers do disable javascripts, how will my html form be submitted? You don't even need a page in order to submit a form to a web server. You can use 'wget' from the command-line to synthesize a request if you're lazy. If you're determined, you can write your own client that feeds everything to the web server and acts just like a web browser. however, i will add some server side validation as well, i agree thats important. I should say so. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx1KEUACgkQ9CaO5/Lv0PCBnwCfahxtdo7urHBQluUyZcq7JyeQ nqUAn02+e1+nw3LfBh/6zRwT3667ngIn =GU9r -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Sessions mix-up on Tomcat 6.0.26 on Linux
On 21/08/2010 05:42, Yawar Khan wrote: chris, i had a look at container managed authentication and its quite handy. but i couldnt see how i can add extra functionality like calling an encryption function on password text field before tomcat does its authentication on it. The Tomcat Documentation is an excellent resource and is worth the time you'll spend reading it. See the 'digest' attribute of the DataSourceRealm. (You are using a DataSource, aren't you?) http://tomcat.apache.org/tomcat-6.0-doc/config/realm.html#Standard_Implementation for js, my client side authentication is done on form submit button click event, if the hackers do disable javascripts, how will my html form be submitted? By pushing the button? By constructing a URL and posting to it using a non-browser script in an automated attack client? however, i will add some server side validation as well, i agree thats important. Don't bother, just use the container auth. That way you don't have to worry about SQL injection attacks, because the SQL isn't poorly cobbled together using String concatenation. p -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Friday, August 20, 2010 3:41 AM To: Tomcat Users List Subject: Re: [OT] Sessions mix-up on Tomcat 6.0.26 on Linux Yawar, On 8/19/2010 3:27 PM, Yawar Saeed Khan/ITG/Karachi wrote: your comments on my current code tells me that this code is not bad, but I should check out tomcat's container managed logins... right? This code seems to be doing more work than necessary. Container-managed authentication and authorization is a useful service provided by the container. I highly recommend taking a look at using it, but it may be ... disruptive to your existing workflows. plus I would like to mention that I have client side form validations (js) to stop query busters. I'm sure that hackers will be sure to leave javascript enabled when they visit your site. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
RE: [OT] Sessions mix-up on Tomcat 6.0.26 on Linux
chris, i had a look at container managed authentication and its quite handy. but i couldnt see how i can add extra functionality like calling an encryption function on password text field before tomcat does its authentication on it. for js, my client side authentication is done on form submit button click event, if the hackers do disable javascripts, how will my html form be submitted? however, i will add some server side validation as well, i agree thats important. -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Friday, August 20, 2010 3:41 AM To: Tomcat Users List Subject: Re: [OT] Sessions mix-up on Tomcat 6.0.26 on Linux -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yawar, On 8/19/2010 3:27 PM, Yawar Saeed Khan/ITG/Karachi wrote: your comments on my current code tells me that this code is not bad, but I should check out tomcat's container managed logins... right? This code seems to be doing more work than necessary. Container-managed authentication and authorization is a useful service provided by the container. I highly recommend taking a look at using it, but it may be ... disruptive to your existing workflows. plus I would like to mention that I have client side form validations (js) to stop query busters. I'm sure that hackers will be sure to leave javascript enabled when they visit your site. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxtsuYACgkQ9CaO5/Lv0PBOsQCgnldndPM7po8wlgYUq6k/QDT3 1mAAoKo/47GXpG4dIEfRNpkZnX/SSveb =zrJ+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Sessions mix-up on Tomcat 6.0.26 on Linux
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yawar,
I'm marking this as off-topic for /your/ request. I just have some
comments for you. Take them or leave them.
On 8/19/2010 11:53 AM, Yawar Saeed Khan/ITG/Karachi wrote:
Ok, let me share my source code with you...
my index.jsp page has a html form which submits the form data to a servlet
called loginmanager.
this is the code inside doPost function;
try {
userbean user = new userbean(); // usebean is a class the has
setter and getter functions for user attributes
user.setUserId(request.getParameter(txt_userid));
user.setPassword(request.getParameter(txt_pass));
user = udac.login(user); //udac is a class that has data access
functions, login function takes user object and checks its existence in db
and sets isValid attribute for that user
Not using Tomcat's container-managed login? Any particular reason why
not? It's quite easy to configure and has the added benefit of being
properly tested.
if (user.isValid()){
HttpSession session = request.getSession(true);
session.setAttribute(user_id,user.getUserId());
session.setAttribute(user_name,user.getName());
session.setAttribute(role_id,user.getRole());
session.setAttribute(role_desc, user.getRoleDesc());
session.setAttribute(last_login, user.getLastLogin());
Why not session.setAttribute(user, user)?
response.sendRedirect(main.jsp); //logged-in page
That should be:
response.sendRedirect(request.getContextPath()
+ response.encodeRedirectURL(/main.jsp));
}else{
response.sendRedirect(index.jsp?user=+user.isValid());
//revert back to login page
That should be:
response.sendRedirect(request.getContextPath()
+ response.encodeRedirectURL(/main.jsp)
+ ?user=
+ java.net.URLEncoder.encode(user.isValid()));
It always helps to format and encode things properly.
}
} finally {
out.close();
}
What is out?
Previously i had tried a simple way; my index.jsp file called itself on form
submit, below code was in index.jsp (no servlet etc);
//after form is submitted
String query = SELECT a.USER_ID,a.NAME, a.BRANCH_CODE, a.PASSWORD,
a.LAST_LOGIN_DATE, a.ROLE_ID, b.ROLE_DESC FROM LOGIN_INFORMATION a, ROLES b
WHERE a.ACTIVE = 'A' AND a.ROLE_ID = b.ROLE_ID ;
query = query + AND LOWER(a.USER_ID) = LOWER('+
request.getParameter(txt_userid) + ') AND a.PASSWORD = '+ epass +';
boolean hasdata=false;
java.sql.ResultSet rs = connection.executeQuery(query);
Wow: this is a SQL injection attack just waiting to happen. What happens
if I submit the txt_userid request parameter as ') OR 1; or, even
better, '); DELETE FROM LOGIN_INFORMATION; or some other evil thing?
I believe that certain JDBC drivers will not execute more than one query
per executeQuery() call, but you can't really count on that. It's easy
to use a PreparedStatement and just do it properly: poof! SQL injection
attacks are a thing of the past (unless the driver is broken, but they
test those things very well).
Also, most SQL databases perform case-insensitive string comparisons, so
your LOWER(a.USER_ID) = LOWER(...) can probably be simplified. Note that
it also means you likely have case-insensitive passwords (though you
haven't shown us what epass is -- is could have been hashed.
while(rs.next()) {
hasdata=true;
session.setAttribute(user_id,rs.getString(USER_ID));
session.setAttribute(user_name,rs.getString(NAME));
session.setAttribute(branch_code,rs.getString(BRANCH_CODE));
session.setAttribute(role_id,rs.getString(ROLE_ID));
session.setAttribute(role_desc,rs.getString(ROLE_DESC));
session.setAttribute(last_login,rs.getString(LAST_LOGIN_DATE));
upsql = UPDATE LOGIN_INFORMATION SET LAST_LOGIN_DATE = SYSDATE
WHERE USER_ID = '+ rs.getString(USER_ID) +';
int up = connection.executeUpdate(UPDATE LOGIN_INFORMATION SET
LAST_LOGIN_DATE = SYSDATE WHERE USER_ID = '+ rs.getString(USER_ID) +');
int audit_insrt = InsertAuditEntry(F001, (String)
session.getAttribute(user_id), (String)
session.getAttribute(branch_code));
response.sendRedirect(main.jsp);
How many redirects do you end up sending? Hopefully, only one. But this
code is bad, bad, bad. It makes me wonder what other nuggets can be
found in your code.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxtY30ACgkQ9CaO5/Lv0PA1pgCcDe1cNVlaqRNlWAbyQVybng4X
OpUAn3ab9KDdsYvVGYzQmoeB871SgUqp
=eEX2
-END PGP
RE: [OT] Sessions mix-up on Tomcat 6.0.26 on Linux
thanks for your constructive comments, as I mentioned that bad, bad, bad code
is out. no longer in the application...
your comments on my current code tells me that this code is not bad, but I
should check out tomcat's container managed logins... right?
plus I would like to mention that I have client side form validations (js) to
stop query busters.
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Thu 19-Aug-10 11:01 PM
To: Tomcat Users List
Subject: Re: [OT] Sessions mix-up on Tomcat 6.0.26 on Linux
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yawar,
I'm marking this as off-topic for /your/ request. I just have some
comments for you. Take them or leave them.
On 8/19/2010 11:53 AM, Yawar Saeed Khan/ITG/Karachi wrote:
Ok, let me share my source code with you...
my index.jsp page has a html form which submits the form data to a servlet
called loginmanager.
this is the code inside doPost function;
try {
userbean user = new userbean(); // usebean is a class the has
setter and getter functions for user attributes
user.setUserId(request.getParameter(txt_userid));
user.setPassword(request.getParameter(txt_pass));
user = udac.login(user); //udac is a class that has data access
functions, login function takes user object and checks its existence in db
and sets isValid attribute for that user
Not using Tomcat's container-managed login? Any particular reason why
not? It's quite easy to configure and has the added benefit of being
properly tested.
if (user.isValid()){
HttpSession session = request.getSession(true);
session.setAttribute(user_id,user.getUserId());
session.setAttribute(user_name,user.getName());
session.setAttribute(role_id,user.getRole());
session.setAttribute(role_desc, user.getRoleDesc());
session.setAttribute(last_login, user.getLastLogin());
Why not session.setAttribute(user, user)?
response.sendRedirect(main.jsp); //logged-in page
That should be:
response.sendRedirect(request.getContextPath()
+ response.encodeRedirectURL(/main.jsp));
}else{
response.sendRedirect(index.jsp?user=+user.isValid());
//revert back to login page
That should be:
response.sendRedirect(request.getContextPath()
+ response.encodeRedirectURL(/main.jsp)
+ ?user=
+ java.net.URLEncoder.encode(user.isValid()));
It always helps to format and encode things properly.
}
} finally {
out.close();
}
What is out?
Previously i had tried a simple way; my index.jsp file called itself on form
submit, below code was in index.jsp (no servlet etc);
//after form is submitted
String query = SELECT a.USER_ID,a.NAME, a.BRANCH_CODE, a.PASSWORD,
a.LAST_LOGIN_DATE, a.ROLE_ID, b.ROLE_DESC FROM LOGIN_INFORMATION a, ROLES b
WHERE a.ACTIVE = 'A' AND a.ROLE_ID = b.ROLE_ID ;
query = query + AND LOWER(a.USER_ID) = LOWER('+
request.getParameter(txt_userid) + ') AND a.PASSWORD = '+ epass +';
boolean hasdata=false;
java.sql.ResultSet rs = connection.executeQuery(query);
Wow: this is a SQL injection attack just waiting to happen. What happens
if I submit the txt_userid request parameter as ') OR 1; or, even
better, '); DELETE FROM LOGIN_INFORMATION; or some other evil thing?
I believe that certain JDBC drivers will not execute more than one query
per executeQuery() call, but you can't really count on that. It's easy
to use a PreparedStatement and just do it properly: poof! SQL injection
attacks are a thing of the past (unless the driver is broken, but they
test those things very well).
Also, most SQL databases perform case-insensitive string comparisons, so
your LOWER(a.USER_ID) = LOWER(...) can probably be simplified. Note that
it also means you likely have case-insensitive passwords (though you
haven't shown us what epass is -- is could have been hashed.
while(rs.next()) {
hasdata=true;
session.setAttribute(user_id,rs.getString(USER_ID));
session.setAttribute(user_name,rs.getString(NAME));
session.setAttribute(branch_code,rs.getString(BRANCH_CODE));
session.setAttribute(role_id,rs.getString(ROLE_ID));
session.setAttribute(role_desc,rs.getString(ROLE_DESC));
session.setAttribute(last_login,rs.getString(LAST_LOGIN_DATE));
upsql = UPDATE LOGIN_INFORMATION SET LAST_LOGIN_DATE = SYSDATE
WHERE USER_ID = '+ rs.getString(USER_ID) +';
int up = connection.executeUpdate(UPDATE LOGIN_INFORMATION SET
LAST_LOGIN_DATE = SYSDATE WHERE USER_ID = '+ rs.getString(USER_ID) +');
int audit_insrt = InsertAuditEntry(F001
Re: [OT] Sessions mix-up on Tomcat 6.0.26 on Linux
Client side validation is for convenience and user feedback. Server side
validation is still required. Nothing requires a user to use a browser, or to
not use extension like Fiddle or Tamper to play with the information once it's
passed your validation scripts.
. . . just my two cents.
/mde/
- Original Message
From: Yawar Saeed Khan/ITG/Karachi yawar.sa...@mcb.com.pk
To: Tomcat Users List users@tomcat.apache.org
Sent: Thu, August 19, 2010 12:27:08 PM
Subject: RE: [OT] Sessions mix-up on Tomcat 6.0.26 on Linux
thanks for your constructive comments, as I mentioned that bad, bad, bad code
is out. no longer in the application...
your comments on my current code tells me that this code is not bad, but I
should check out tomcat's container managed logins... right?
plus I would like to mention that I have client side form validations (js) to
stop query busters.
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Thu 19-Aug-10 11:01 PM
To: Tomcat Users List
Subject: Re: [OT] Sessions mix-up on Tomcat 6.0.26 on Linux
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yawar,
I'm marking this as off-topic for /your/ request. I just have some
comments for you. Take them or leave them.
On 8/19/2010 11:53 AM, Yawar Saeed Khan/ITG/Karachi wrote:
Ok, let me share my source code with you...
my index.jsp page has a html form which submits the form data to a servlet
called loginmanager.
this is the code inside doPost function;
try {
userbean user = new userbean(); // usebean is a class the has
setter and getter functions for user attributes
user.setUserId(request.getParameter(txt_userid));
user.setPassword(request.getParameter(txt_pass));
user = udac.login(user); //udac is a class that has data access
functions, login function takes user object and checks its existence in db and
sets isValid attribute for that user
Not using Tomcat's container-managed login? Any particular reason why
not? It's quite easy to configure and has the added benefit of being
properly tested.
if (user.isValid()){
HttpSession session = request.getSession(true);
session.setAttribute(user_id,user.getUserId());
session.setAttribute(user_name,user.getName());
session.setAttribute(role_id,user.getRole());
session.setAttribute(role_desc, user.getRoleDesc());
session.setAttribute(last_login, user.getLastLogin());
Why not session.setAttribute(user, user)?
response.sendRedirect(main.jsp); //logged-in page
That should be:
response.sendRedirect(request.getContextPath()
+ response.encodeRedirectURL(/main.jsp));
}else{
response.sendRedirect(index.jsp?user=+user.isValid());
//revert back to login page
That should be:
response.sendRedirect(request.getContextPath()
+ response.encodeRedirectURL(/main.jsp)
+ ?user=
+ java.net.URLEncoder.encode(user.isValid()));
It always helps to format and encode things properly.
}
} finally {
out.close();
}
What is out?
Previously i had tried a simple way; my index.jsp file called itself on form
submit, below code was in index.jsp (no servlet etc);
//after form is submitted
String query = SELECT a.USER_ID,a.NAME, a.BRANCH_CODE, a.PASSWORD,
a.LAST_LOGIN_DATE, a.ROLE_ID, b.ROLE_DESC FROM LOGIN_INFORMATION a, ROLES b
WHERE a.ACTIVE = 'A' AND a.ROLE_ID = b.ROLE_ID ;
query = query + AND LOWER(a.USER_ID) = LOWER('+
request.getParameter(txt_userid) + ') AND a.PASSWORD = '+ epass +';
boolean hasdata=false;
java.sql.ResultSet rs = connection.executeQuery(query);
Wow: this is a SQL injection attack just waiting to happen. What happens
if I submit the txt_userid request parameter as ') OR 1; or, even
better, '); DELETE FROM LOGIN_INFORMATION; or some other evil thing?
I believe that certain JDBC drivers will not execute more than one query
per executeQuery() call, but you can't really count on that. It's easy
to use a PreparedStatement and just do it properly: poof! SQL injection
attacks are a thing of the past (unless the driver is broken, but they
test those things very well).
Also, most SQL databases perform case-insensitive string comparisons, so
your LOWER(a.USER_ID) = LOWER(...) can probably be simplified. Note that
it also means you likely have case-insensitive passwords (though you
haven't shown us what epass is -- is could have been hashed.
while(rs.next()) {
hasdata=true;
session.setAttribute(user_id,rs.getString(USER_ID));
session.setAttribute(user_name,rs.getString(NAME));
session.setAttribute(branch_code,rs.getString(BRANCH_CODE
Re: [OT] Sessions mix-up on Tomcat 6.0.26 on Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yawar, On 8/19/2010 3:27 PM, Yawar Saeed Khan/ITG/Karachi wrote: your comments on my current code tells me that this code is not bad, but I should check out tomcat's container managed logins... right? This code seems to be doing more work than necessary. Container-managed authentication and authorization is a useful service provided by the container. I highly recommend taking a look at using it, but it may be ... disruptive to your existing workflows. plus I would like to mention that I have client side form validations (js) to stop query busters. I'm sure that hackers will be sure to leave javascript enabled when they visit your site. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxtsuYACgkQ9CaO5/Lv0PBOsQCgnldndPM7po8wlgYUq6k/QDT3 1mAAoKo/47GXpG4dIEfRNpkZnX/SSveb =zrJ+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
