5 replaced http://meta.security.stackexchange.com/ with https://security.meta.stackexchange.com/
source | link

A little background info here: I'm a self-taught web developer with very little experience outside of html/css, and the company I work for has hired a third party web development team to design us an e-commerce site. Anyway, I was beta testing the site today using the TamperData Firefox add-on, and I found two major design flaws which both involve HTTP headers.

The first flaw was that when our site asks the user to choose a freight option (ground, express, etc.) the site passes the calculated freight value back to the server in an HTTP header. By manipulating the header, I was able to modify (see: erase) the freight value and so the backend interpreted the calculated freight value as 0, and so it didn't charge me freight!

The second flaw, however, is far worse... When the total product value is calculated and I "checkout", all of the transaction information (CC#, CVV2, Expiry, $ total) gets passed to a third party merchant processor via an HTTP header. Once again, I used TamperData and was able to manipulate the header so that the $ value being sent to the merchant was something trivial (I choose $1 for the test).

The fact that I -- with absolutely no experience in website security or server side coding -- was able to find these severe flaws has me completely scared, because what does that say about the programmers who designed this? Sure, they will probably fix these two issues somehow. BUT, If sending credit card data in a plaintext HTTP header seemed like a good idea to them, will their new solution realistically be any more secure? What if there are other, completely separate attack vectors that I missed?

Thus, my questions for you:

  1. Given the information above, what steps would you take to avoid these security holes? (so I know what to request our programmers to do)

  2. What books, sites, and/or resources are available so I may teach myself about web security, and how to do actual penetration testing? It will take some time for my company to arrange for an outside security audit, and in the interim I want to fix as much of the site as possible.

UPDATE:

As I said in a comment below, I am interested to know exactly how secure it is to transmit the payment info in an http header to the cc merchant (we are using an https connection if that matters). Can third parties eavesdrop or intercept these packets? And if they can, is that a realistic scenario, or is it highly unlikely? I ask this because I don't yet have a good understanding of how transmitting data via HTTP headers works, at least on a technical level.

This question was IT Security Question of the WeekIT Security Question of the Week.
Read the Aug 12, 2011 blog entry for more details or submit your ownsubmit your own Question of the Week.

A little background info here: I'm a self-taught web developer with very little experience outside of html/css, and the company I work for has hired a third party web development team to design us an e-commerce site. Anyway, I was beta testing the site today using the TamperData Firefox add-on, and I found two major design flaws which both involve HTTP headers.

The first flaw was that when our site asks the user to choose a freight option (ground, express, etc.) the site passes the calculated freight value back to the server in an HTTP header. By manipulating the header, I was able to modify (see: erase) the freight value and so the backend interpreted the calculated freight value as 0, and so it didn't charge me freight!

The second flaw, however, is far worse... When the total product value is calculated and I "checkout", all of the transaction information (CC#, CVV2, Expiry, $ total) gets passed to a third party merchant processor via an HTTP header. Once again, I used TamperData and was able to manipulate the header so that the $ value being sent to the merchant was something trivial (I choose $1 for the test).

The fact that I -- with absolutely no experience in website security or server side coding -- was able to find these severe flaws has me completely scared, because what does that say about the programmers who designed this? Sure, they will probably fix these two issues somehow. BUT, If sending credit card data in a plaintext HTTP header seemed like a good idea to them, will their new solution realistically be any more secure? What if there are other, completely separate attack vectors that I missed?

Thus, my questions for you:

  1. Given the information above, what steps would you take to avoid these security holes? (so I know what to request our programmers to do)

  2. What books, sites, and/or resources are available so I may teach myself about web security, and how to do actual penetration testing? It will take some time for my company to arrange for an outside security audit, and in the interim I want to fix as much of the site as possible.

UPDATE:

As I said in a comment below, I am interested to know exactly how secure it is to transmit the payment info in an http header to the cc merchant (we are using an https connection if that matters). Can third parties eavesdrop or intercept these packets? And if they can, is that a realistic scenario, or is it highly unlikely? I ask this because I don't yet have a good understanding of how transmitting data via HTTP headers works, at least on a technical level.

This question was IT Security Question of the Week.
Read the Aug 12, 2011 blog entry for more details or submit your own Question of the Week.

A little background info here: I'm a self-taught web developer with very little experience outside of html/css, and the company I work for has hired a third party web development team to design us an e-commerce site. Anyway, I was beta testing the site today using the TamperData Firefox add-on, and I found two major design flaws which both involve HTTP headers.

The first flaw was that when our site asks the user to choose a freight option (ground, express, etc.) the site passes the calculated freight value back to the server in an HTTP header. By manipulating the header, I was able to modify (see: erase) the freight value and so the backend interpreted the calculated freight value as 0, and so it didn't charge me freight!

The second flaw, however, is far worse... When the total product value is calculated and I "checkout", all of the transaction information (CC#, CVV2, Expiry, $ total) gets passed to a third party merchant processor via an HTTP header. Once again, I used TamperData and was able to manipulate the header so that the $ value being sent to the merchant was something trivial (I choose $1 for the test).

The fact that I -- with absolutely no experience in website security or server side coding -- was able to find these severe flaws has me completely scared, because what does that say about the programmers who designed this? Sure, they will probably fix these two issues somehow. BUT, If sending credit card data in a plaintext HTTP header seemed like a good idea to them, will their new solution realistically be any more secure? What if there are other, completely separate attack vectors that I missed?

Thus, my questions for you:

  1. Given the information above, what steps would you take to avoid these security holes? (so I know what to request our programmers to do)

  2. What books, sites, and/or resources are available so I may teach myself about web security, and how to do actual penetration testing? It will take some time for my company to arrange for an outside security audit, and in the interim I want to fix as much of the site as possible.

UPDATE:

As I said in a comment below, I am interested to know exactly how secure it is to transmit the payment info in an http header to the cc merchant (we are using an https connection if that matters). Can third parties eavesdrop or intercept these packets? And if they can, is that a realistic scenario, or is it highly unlikely? I ask this because I don't yet have a good understanding of how transmitting data via HTTP headers works, at least on a technical level.

This question was IT Security Question of the Week.
Read the Aug 12, 2011 blog entry for more details or submit your own Question of the Week.

4 Added qotw banner.
source | link

I just discovered major security flaws in my web store!?

A little background info here: I'm a self-taught web developer with very little experience outside of html/css, and the company I work for has hired a third party web development team to design us an e-commerce site. Anyway, I was beta testing the site today using the TamperData Firefox add-on, and I found two major design flaws which both involve HTTP headers.

The first flaw was that when our site asks the user to choose a freight option (ground, express, etc.) the site passes the calculated freight value back to the server in an HTTP header. By manipulating the header, I was able to modify (see: erase) the freight value and so the backend interpreted the calculated freight value as 0, and so it didn't charge me freight!

The second flaw, however, is far worse... When the total product value is calculated and I "checkout", all of the transaction information (CC#, CVV2, Expiry, $ total) gets passed to a third party merchant processor via an HTTP header. Once again, I used TamperData and was able to manipulate the header so that the $ value being sent to the merchant was something trivial (I choose $1 for the test).

The fact that I -- with absolutely no experience in website security or server side coding -- was able to find these severe flaws has me completely scared, because what does that say about the programmers who designed this? Sure, they will probably fix these two issues somehow. BUT, If sending credit card data in a plaintext HTTP header seemed like a good idea to them, will their new solution realistically be any more secure? What if there are other, completely separate attack vectors that I missed?

Thus, my questions for you:

  1. Given the information above, what steps would you take to avoid these security holes? (so I know what to request our programmers to do)

  2. What books, sites, and/or resources are available so I may teach myself about web security, and how to do actual penetration testing? It will take some time for my company to arrange for an outside security audit, and in the interim I want to fix as much of the site as possible.

UPDATE:

As I said in a comment below, I am interested to know exactly how secure it is to transmit the payment info in an http header to the cc merchant (we are using an https connection if that matters). Can third parties eavesdrop or intercept these packets? And if they can, is that a realistic scenario, or is it highly unlikely? I ask this because I don't yet have a good understanding of how transmitting data via HTTP headers works, at least on a technical level.

This question was IT Security Question of the Week.
Read the Aug 12, 2011 blog entry for more details or submit your own Question of the Week.

I just discovered major security flaws in my web store!

A little background info here: I'm a self-taught web developer with very little experience outside of html/css, and the company I work for has hired a third party web development team to design us an e-commerce site. Anyway, I was beta testing the site today using the TamperData Firefox add-on, and I found two major design flaws which both involve HTTP headers.

The first flaw was that when our site asks the user to choose a freight option (ground, express, etc.) the site passes the calculated freight value back to the server in an HTTP header. By manipulating the header, I was able to modify (see: erase) the freight value and so the backend interpreted the calculated freight value as 0, and so it didn't charge me freight!

The second flaw, however, is far worse... When the total product value is calculated and I "checkout", all of the transaction information (CC#, CVV2, Expiry, $ total) gets passed to a third party merchant processor via an HTTP header. Once again, I used TamperData and was able to manipulate the header so that the $ value being sent to the merchant was something trivial (I choose $1 for the test).

The fact that I -- with absolutely no experience in website security or server side coding -- was able to find these severe flaws has me completely scared, because what does that say about the programmers who designed this? Sure, they will probably fix these two issues somehow. BUT, If sending credit card data in a plaintext HTTP header seemed like a good idea to them, will their new solution realistically be any more secure? What if there are other, completely separate attack vectors that I missed?

Thus, my questions for you:

  1. Given the information above, what steps would you take to avoid these security holes? (so I know what to request our programmers to do)

  2. What books, sites, and/or resources are available so I may teach myself about web security, and how to do actual penetration testing? It will take some time for my company to arrange for an outside security audit, and in the interim I want to fix as much of the site as possible.

UPDATE:

As I said in a comment below, I am interested to know exactly how secure it is to transmit the payment info in an http header to the cc merchant (we are using an https connection if that matters). Can third parties eavesdrop or intercept these packets? And if they can, is that a realistic scenario, or is it highly unlikely? I ask this because I don't yet have a good understanding of how transmitting data via HTTP headers works, at least on a technical level.

I just discovered major security flaws in my web store?

A little background info here: I'm a self-taught web developer with very little experience outside of html/css, and the company I work for has hired a third party web development team to design us an e-commerce site. Anyway, I was beta testing the site today using the TamperData Firefox add-on, and I found two major design flaws which both involve HTTP headers.

The first flaw was that when our site asks the user to choose a freight option (ground, express, etc.) the site passes the calculated freight value back to the server in an HTTP header. By manipulating the header, I was able to modify (see: erase) the freight value and so the backend interpreted the calculated freight value as 0, and so it didn't charge me freight!

The second flaw, however, is far worse... When the total product value is calculated and I "checkout", all of the transaction information (CC#, CVV2, Expiry, $ total) gets passed to a third party merchant processor via an HTTP header. Once again, I used TamperData and was able to manipulate the header so that the $ value being sent to the merchant was something trivial (I choose $1 for the test).

The fact that I -- with absolutely no experience in website security or server side coding -- was able to find these severe flaws has me completely scared, because what does that say about the programmers who designed this? Sure, they will probably fix these two issues somehow. BUT, If sending credit card data in a plaintext HTTP header seemed like a good idea to them, will their new solution realistically be any more secure? What if there are other, completely separate attack vectors that I missed?

Thus, my questions for you:

  1. Given the information above, what steps would you take to avoid these security holes? (so I know what to request our programmers to do)

  2. What books, sites, and/or resources are available so I may teach myself about web security, and how to do actual penetration testing? It will take some time for my company to arrange for an outside security audit, and in the interim I want to fix as much of the site as possible.

UPDATE:

As I said in a comment below, I am interested to know exactly how secure it is to transmit the payment info in an http header to the cc merchant (we are using an https connection if that matters). Can third parties eavesdrop or intercept these packets? And if they can, is that a realistic scenario, or is it highly unlikely? I ask this because I don't yet have a good understanding of how transmitting data via HTTP headers works, at least on a technical level.

This question was IT Security Question of the Week.
Read the Aug 12, 2011 blog entry for more details or submit your own Question of the Week.

3 added additional question
source | link

A little background info here: I'm a self-taught web developer with very little experience outside of html/css, and the company I work for has hired a third party web development team to design us an e-commerce site. Anyway, I was beta testing the site today using the TamperData Firefox add-on, and I found two major design flaws which both involve HTTP headers.

The first flaw was that when our site asks the user to choose a freight option (ground, express, etc.) the site passes the calculated freight value back to the server in an HTTP header. By manipulating the header, I was able to modify (see: erase) the freight value and so the backend interpreted the calculated freight value as 0, and so it didn't charge me freight!

The second flaw, however, is far worse... When the total product value is calculated and I "checkout", all of the transaction information (CC#, CVV2, Expiry, $ total) gets passed to a third party merchant processor via an HTTP header. Once again, I used TamperData and was able to manipulate the header so that the $ value being sent to the merchant was something trivial (I choose $1 for the test).

The fact that I -- with absolutely no experience in website security or server side coding -- was able to find these severe flaws has me completely scared, because what does that say about the programmers who designed this? Sure, they will probably fix these two issues somehow. BUT, If sending credit card data in a plaintext HTTP header seemed like a good idea to them, will their new solution realistically be any more secure? What if there are other, completely separate attack vectors that I missed?

Thus, my questions for you:

  1. Given the information above, what steps would you take to avoid these security holes? (so I know what to request our programmers to do)

  2. What books, sites, and/or resources are available so I may teach myself about web security, and how to do actual penetration testing? It will take some time for my company to arrange for an outside security audit, and in the interim I want to fix as much of the site as possible.

UPDATE:

As I said in a comment below, I am interested to know exactly how secure it is to transmit the payment info in an http header to the cc merchant (we are using an https connection if that matters). Can third parties eavesdrop or intercept these packets? And if they can, is that a realistic scenario, or is it highly unlikely? I ask this because I don't yet have a good understanding of how transmitting data via HTTP headers works, at least on a technical level.

A little background info here: I'm a self-taught web developer with very little experience outside of html/css, and the company I work for has hired a third party web development team to design us an e-commerce site. Anyway, I was beta testing the site today using the TamperData Firefox add-on, and I found two major design flaws which both involve HTTP headers.

The first flaw was that when our site asks the user to choose a freight option (ground, express, etc.) the site passes the calculated freight value back to the server in an HTTP header. By manipulating the header, I was able to modify (see: erase) the freight value and so the backend interpreted the calculated freight value as 0, and so it didn't charge me freight!

The second flaw, however, is far worse... When the total product value is calculated and I "checkout", all of the transaction information (CC#, CVV2, Expiry, $ total) gets passed to a third party merchant processor via an HTTP header. Once again, I used TamperData and was able to manipulate the header so that the $ value being sent to the merchant was something trivial (I choose $1 for the test).

The fact that I -- with absolutely no experience in website security or server side coding -- was able to find these severe flaws has me completely scared, because what does that say about the programmers who designed this? Sure, they will probably fix these two issues somehow. BUT, If sending credit card data in a plaintext HTTP header seemed like a good idea to them, will their new solution realistically be any more secure? What if there are other, completely separate attack vectors that I missed?

Thus, my questions for you:

  1. Given the information above, what steps would you take to avoid these security holes? (so I know what to request our programmers to do)

  2. What books, sites, and/or resources are available so I may teach myself about web security, and how to do actual penetration testing? It will take some time for my company to arrange for an outside security audit, and in the interim I want to fix as much of the site as possible.

A little background info here: I'm a self-taught web developer with very little experience outside of html/css, and the company I work for has hired a third party web development team to design us an e-commerce site. Anyway, I was beta testing the site today using the TamperData Firefox add-on, and I found two major design flaws which both involve HTTP headers.

The first flaw was that when our site asks the user to choose a freight option (ground, express, etc.) the site passes the calculated freight value back to the server in an HTTP header. By manipulating the header, I was able to modify (see: erase) the freight value and so the backend interpreted the calculated freight value as 0, and so it didn't charge me freight!

The second flaw, however, is far worse... When the total product value is calculated and I "checkout", all of the transaction information (CC#, CVV2, Expiry, $ total) gets passed to a third party merchant processor via an HTTP header. Once again, I used TamperData and was able to manipulate the header so that the $ value being sent to the merchant was something trivial (I choose $1 for the test).

The fact that I -- with absolutely no experience in website security or server side coding -- was able to find these severe flaws has me completely scared, because what does that say about the programmers who designed this? Sure, they will probably fix these two issues somehow. BUT, If sending credit card data in a plaintext HTTP header seemed like a good idea to them, will their new solution realistically be any more secure? What if there are other, completely separate attack vectors that I missed?

Thus, my questions for you:

  1. Given the information above, what steps would you take to avoid these security holes? (so I know what to request our programmers to do)

  2. What books, sites, and/or resources are available so I may teach myself about web security, and how to do actual penetration testing? It will take some time for my company to arrange for an outside security audit, and in the interim I want to fix as much of the site as possible.

UPDATE:

As I said in a comment below, I am interested to know exactly how secure it is to transmit the payment info in an http header to the cc merchant (we are using an https connection if that matters). Can third parties eavesdrop or intercept these packets? And if they can, is that a realistic scenario, or is it highly unlikely? I ask this because I don't yet have a good understanding of how transmitting data via HTTP headers works, at least on a technical level.

    Tweeted twitter.com/#!/StackSecurity/status/96273867353501696
2 Added some tags
| link
    Post Migrated Here from serverfault.com
1
source | link