• Toll-free  888-665-8637
  • International  +1 717-220-0012
Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

gtestamark
#1 Posted : Sunday, May 25, 2008 11:15:14 AM(UTC)
gtestamark

Rank: Member

Joined: 4/11/2008(UTC)
Posts: 10

I put Hackersafe on my site Justlinen.com, For some reason BV5 has a security hole in their application. It has a problem creating a secure cookie at check out.



Severity Name Port Category
Default Microsoft IIS Files and/or Frontpage Extensions Found 443/tcp Other
Description

Default files and/or directories were found during the web application crawl.

Default Files provide a way for an attacker to fingerprint the web server. Previous default IIS files have been known to contain code that could potentially allow an attacker to run arbitrary code on the web server.

Frontpage allows remote web developers and administrators to modify web content from a remote location. This provides a serious business risk to the company if left implemented.

CVSS2# 5, CVE-2000-0114, (AV:N/AC:L/Au:N/C:P/I:N/A:N)
Solution

IMPORTANT: Be sure to remove FrontPage if you are not using it. Frontpage is often installed by default.

If there is a business need to run FrontPage on the web server, then remove all anonymous access to all FrontPage extensions (such as _vti_bin) which may be mapped on your website as a virtual directory.

If default IIS files were found, remove them from the web server.
References

CVE CVE-2000-0114
Open Source Vulnerability Database 67


Severity Name Port Category
Missing Secure Attribute in an Encrypted Session (SSL) Cookie 443/tcp Web Application
Description

The application sets a cookie over a secure channel without using the "secure" attribute. RFC states that if the cookie does not have the secure attribute assigned to it, then the cookie can be passed to the server by the client over non-secure channels (http). Using this attack, an attacker may be able to intercept this cookie, over the non-secure channel, and use it for a session hijacking attack.
Solution

It is best business practice that any cookies that are sent (set-cookie) over an SSL connection to explicitly state secure on them.
References

None


Severity Name Port Category
Default Microsoft IIS Files and/or Frontpage Extensions Found 80/tcp Other
Description

Default files and/or directories were found during the web application crawl.

Default Files provide a way for an attacker to fingerprint the web server. Previous default IIS files have been known to contain code that could potentially allow an attacker to run arbitrary code on the web server.

Frontpage allows remote web developers and administrators to modify web content from a remote location. This provides a serious business risk to the company if left implemented.

CVSS2# 5, CVE-2000-0114, (AV:N/AC:L/Au:N/C:P/I:N/A:N)
Solution

IMPORTANT: Be sure to remove FrontPage if you are not using it. Frontpage is often installed by default.

If there is a business need to run FrontPage on the web server, then remove all anonymous access to all FrontPage extensions (such as _vti_bin) which may be mapped on your website as a virtual directory.

If default IIS files were found, remove them from the web server.
References

CVE CVE-2000-0114
Open Source Vulnerability Database 67


Severity Name Port Category
Missing Secure Attribute in an Encrypted Session (SSL) Cookie 8443/tcp Web Application
Description

The application sets a cookie over a secure channel without using the "secure" attribute. RFC states that if the cookie does not have the secure attribute assigned to it, then the cookie can be passed to the server by the client over non-secure channels (http). Using this attack, an attacker may be able to intercept this cookie, over the non-secure channel, and use it for a session hijacking attack.
Solution

It is best business practice that any cookies that are sent (set-cookie) over an SSL connection to explicitly state secure on them.
References

None


Severity Name Port Category
Potentially Sensitive Information Missing Secure Attribute in an Encrypted Session (SSL) Cookie 8443/tcp Web Application
Description

The application sets a cookie over a secure channel without using the "secure" attribute. RFC states that if the cookie does not have the secure attribute assigned to it, then the cookie can be passed to the server by the client over non-secure channels (http). Using this attack, an attacker may be able to intercept this cookie, over the non-secure channel, and use it for a session hijacking attack. The information that was sent was flagged as being potentially sensitive. Potentially sensitive information could be session tokens, user id's, or passwords.
Solution

It is best business practice that any cookies that are sent (set-cookie) over an SSL connection to explicitly state secure on them.
References

Other No References Available


Severity Name Port Category
Directory Scanner 443/tcp Web Application
Description

During an audit common directories are looked for. This may result in non public Web pages being found.
Solution

Make sure that these directories are intended for the public.
References

None


Severity Name Port Category
Directory Scanner 80/tcp Web Application
Description

During an audit common directories are looked for. This may result in non public Web pages being found.
Solution

Make sure that these directories are intended for the public.
References

None
Andy Miller
#2 Posted : Sunday, May 25, 2008 2:15:30 PM(UTC)
Andy Miller

Rank: Member

Joined: 11/5/2003(UTC)
Posts: 2,136

Was thanked: 1 time(s) in 1 post(s)
Add this method to your Global.asax file to append the "secure" attribute to any Set-cookie that is issued over https,


Code:

Protected Sub Application_EndRequest(ByVal sender As Object, ByVal e As System.EventArgs)
If Request.IsSecureConnection Then
For Each [b][/b][b][/b]cookie As String In Response.[b][/b][b][/b]cookies
Response.[b][/b][b][/b]cookies([b][/b][b][/b]cookie).Secure = True
Next
End If
End Sub


In my simple testing, two cookies were set during checkout:
<OL>
<LI>The userid cookie, but only if the customer signs in during checkout, and checks Remember Me.
* The cartid cookie (to an empty string) after checkout is completed, presumably to "clear" the cart.
</OL>
In practice, this will prevent the browser from "remembering" who you are between sessions. If you login over a https, and check "Remember Me"; the userid cookie will be sent to your browser with the "secure" attribute. If you close your browser, then open it again and navigate to the home page over http, the userid cookie will not be sent to the server, and the store will not "remember" you.

To avoid frustrating your customers, I recommend disabling the "Remember Users" option (BV Admin &gt; Options &gt; Site Settings &gt; Users) if you have enabled SSL (BV Admin &gt; Options &gt; Security) and implement the code above.

Ironically, if you disable "Remember Users", then the only cookies that are set during checkout are empty values to clear the userid and cartid cookies. Hardly a "huge" security issue.
Andy Miller
Structured Solutions

Shipper 3 - High Velocity Shipment Processing
Marcus
#3 Posted : Sunday, May 25, 2008 3:17:40 PM(UTC)
Marcus

Rank: Member

Joined: 11/5/2003(UTC)
Posts: 1,786

Hackersafe and other security scans run through a huge list of possible security problems and report it as a possible problem. It's up to the software developer, web host, and store owner to review the information and determine the true risk.

For example: If I have a database server and install IIS some admins would consider that a security hole because port 80 is not needed on a SQL server. In the same way, if I have SQL server installed on a web box with named pipes available that could be considered a security hole.

The "Remember Me" cookie is the only one that can really be abused and it's easily disabled. If you use that cookie and login from a public computer, every other person that uses the computer can access your BV account because it's been "remembered." This is one of the main reasons why we don't ever store or display credit card information back to customers. Too much risk.

We opted to go for the much more user friendly option that meant they didn't loose a cart if the app pool recycled in a trade off for a slight bit of risk in a very specific circumstance.

Andy's code looks like it would work but would require dual logins to both non-ssl and ssl portions of your store.
birdsafe
#4 Posted : Sunday, May 25, 2008 5:43:17 PM(UTC)
birdsafe

Rank: Member

Joined: 2/21/2007(UTC)
Posts: 1,113

I've never seen that with HackerSafe on my BV site -- perhaps it is host related or SSL related
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

©2024 Develisys. All rights reserved.
  • Toll-free  888-665-8637
  • International  +1 717-220-0012