So section 3.7.5 if the DISA Application Security and Development STIG V3R1 seems to be the requirement in question, but who is it that's saying that a properly configured TLS/SSL connection doesn't meet the requirement, and why? I question how the STIG is being read here.
I agree with Robert that there's no reason to trust SSL any less than a client-side JavaScript implementation. (Actually, I worry a bit more about potential bugs in the JavaScript, which is probably less mature than the TLS code.)
The local code should probably make sure that the connection back to the server is using TLS, that the server certificate is valid (correct name, not expired, valid for use as a TLS server, not revoked, issued by a recognized CA and so on), and that the agreed algorithms use a sufficiently strong hashing algorithm.
On Jul 21, 2010, at 12:11 PM, Robert Hajime Lanning wrote:
> Well, outside of an AES128-SHA1 SSL connection, there really isn't much that can
> be done for transit protection.
>
> I would not trust any JavaScript implementation of form data hashing.
> Since that is
> all modifiable on the client side.
>
> If you can't even trust certificates, how are you going to trust the
> client platform?
>
> On Wed, Jul 21, 2010 at 8:26 AM, Richard High <RichardHigh (at) imgva (dot) com [email concealed]> wrote:
>> HTTPS is already configured. This doesn't meet the required baseline
>> security for web apps. According to published DISA directives.
>>
>> Richard High Security Engineer, CISSP
>> Information Management Group, Inc.
>> Richard.A.High (at) us.army (dot) mil [email concealed]
>> RichardHigh (at) imgva (dot) com [email concealed]
>> NSA:rahigh (at) nsa.ic (dot) gov [email concealed]
>> SIPR: Richard.A.High (at) us.army.smil (dot) mil [email concealed]
>> JWICS: Richard.High (at) dami.ic (dot) gov [email concealed]
>> Work Location Fairfax: (703)573-5000x401
>> Pentagon Fax: (703) 695-3070
>> 4050 Legarto Rd Suite 200
>> Fairfax, VA 22033
>>
>> ________________________________
>> From: listbounce (at) securityfocus (dot) com [email concealed] on behalf of Robert Hajime Lanning
>> Sent: Tue 7/20/2010 6:42 PM
>> To: webappsec (at) securityfocus (dot) com [email concealed]
>> Subject: Re: Hash for data in transit
>>
>> On Tue, Jul 20, 2010 at 1:03 PM, <richardhigh (at) imgva (dot) com [email concealed]> wrote:
>>> Does anyone know of any tools out there that can be used to ensure
>>> the integrity of data while in transit from a web app and a user
>>> using a website to enter information?
>>
>> https will between the browser and the webserver.
>>
>
> --
> And, did Galoka think the Ulus were too ugly to save?
> -Centauri
>
>
>
> This list is sponsored by Cenzic
> --------------------------------------
> Let Us Hack You. Before Hackers Do!
> It's Finally Here - The Cenzic Website HealthCheck. FREE.
> Request Yours Now!
> http://www.cenzic.com/2009HClaunch_Securityfocus
> --------------------------------------
>
This list is sponsored by Cenzic
--------------------------------------
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now!
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------
I agree with Robert that there's no reason to trust SSL any less than a client-side JavaScript implementation. (Actually, I worry a bit more about potential bugs in the JavaScript, which is probably less mature than the TLS code.)
The local code should probably make sure that the connection back to the server is using TLS, that the server certificate is valid (correct name, not expired, valid for use as a TLS server, not revoked, issued by a recognized CA and so on), and that the agreed algorithms use a sufficiently strong hashing algorithm.
On Jul 21, 2010, at 12:11 PM, Robert Hajime Lanning wrote:
> Well, outside of an AES128-SHA1 SSL connection, there really isn't much that can
> be done for transit protection.
>
> I would not trust any JavaScript implementation of form data hashing.
> Since that is
> all modifiable on the client side.
>
> If you can't even trust certificates, how are you going to trust the
> client platform?
>
> On Wed, Jul 21, 2010 at 8:26 AM, Richard High <RichardHigh (at) imgva (dot) com [email concealed]> wrote:
>> HTTPS is already configured. This doesn't meet the required baseline
>> security for web apps. According to published DISA directives.
>>
>> Richard High Security Engineer, CISSP
>> Information Management Group, Inc.
>> Richard.A.High (at) us.army (dot) mil [email concealed]
>> RichardHigh (at) imgva (dot) com [email concealed]
>> NSA:rahigh (at) nsa.ic (dot) gov [email concealed]
>> SIPR: Richard.A.High (at) us.army.smil (dot) mil [email concealed]
>> JWICS: Richard.High (at) dami.ic (dot) gov [email concealed]
>> Work Location Fairfax: (703)573-5000x401
>> Pentagon Fax: (703) 695-3070
>> 4050 Legarto Rd Suite 200
>> Fairfax, VA 22033
>>
>> ________________________________
>> From: listbounce (at) securityfocus (dot) com [email concealed] on behalf of Robert Hajime Lanning
>> Sent: Tue 7/20/2010 6:42 PM
>> To: webappsec (at) securityfocus (dot) com [email concealed]
>> Subject: Re: Hash for data in transit
>>
>> On Tue, Jul 20, 2010 at 1:03 PM, <richardhigh (at) imgva (dot) com [email concealed]> wrote:
>>> Does anyone know of any tools out there that can be used to ensure
>>> the integrity of data while in transit from a web app and a user
>>> using a website to enter information?
>>
>> https will between the browser and the webserver.
>>
>
> --
> And, did Galoka think the Ulus were too ugly to save?
> -Centauri
>
>
>
> This list is sponsored by Cenzic
> --------------------------------------
> Let Us Hack You. Before Hackers Do!
> It's Finally Here - The Cenzic Website HealthCheck. FREE.
> Request Yours Now!
> http://www.cenzic.com/2009HClaunch_Securityfocus
> --------------------------------------
>
This list is sponsored by Cenzic
--------------------------------------
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now!
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------
[ reply ]