Security of HTTP within Corporate LAN

0 投票
最新提问 用户: (160 分)

I'm writing a network application for enterprises wherein I intend to run an HTTP server on almost all hosts within a LAN. Some people have told me that this is a huge security hole because HTTP is often allowed through corporate firewalls and therefore by running an HTTP server on every node I'll potentially expose all of them to the outside. Is this a genuine risk?

As per my understanding the firewall exception for HTTP is generally based on the port number 80, not based on the inspection of packet contents. Therefore, if I run my HTTP server on a port other than 80 then the firewall will not allow access to it and hence I should be fine. Is this understanding correct?

I know there are application firewalls, but I'm not quite able to fathom how they operate within a typical corporate network or how common they are in the enterprise world. Any information on this will be helpful.

Update

The application referred to above is a P2P content sharing application whose operation is entirely confined within a subnet. I wish to use HTTP for the transfer for content from one node to another. The reason for choosing HTTP is that it is simple to implement and provides many application level features such as PUTs and DELETEs out of the box. My concern here is if choosing HTTP automatically puts all nodes at a security risk because typically corporate firewalls (by which I mean NATs) typically allow inbound HTTP traffic from outside the network.

发表于 用户: (140 分)
Assuming your application is behind a NAT firewall, external connections likely won't be able to reach your internal servers anyway...are you planning on making these ports available outside the network? Security by obscurity (changing a port) is not good security - a port scanner will pick up the changed port very quickly.
发表于 用户: (160 分)
No, I do not want to make these ports available outside of the network.

2 个回答

0 投票
最新回答 用户: (140 分)

Do not assume that you're secure just because you're behind a firewall.

If Web browsers inside the firewall can access both internal and external sites, an external site can probe the internal sites and convince the browsers to send requests to them.

This is an extremely common problem; the simplest example is the attacks against home DSL router administrative interfaces.

0 投票
最新回答 用户: (360 分)

If your only concern is attackers being able to directly connect to your HTTP server from outside of the corporate network, then this is unlikely due to NAT, as roelofs commented.

But is this truly your only concern? You have not specified what your application does, but is it acceptable to you (and to your users) that people inside the corporate network will be able to sniff your application's traffic? Is it acceptable that attackers who penetrate the network (and this happens all the time) can intercept, replay, and tamper with the traffic?

Why would you not use HTTPS?

发表于 用户: (160 分)
I do intent to use both HTTP and HTTPS depending on the situation (i.e. user requires as secure transfer or not)
发表于 用户: (360 分)
Reading your edited question - HTTPS is basically HTTP over TLS. It will provide you with the same REST semantics (PUT, DELETE, etc.) out of the box, with the additional upside of being secure. Choosing HTTP will put all nodes at risk, but not because it'll open them up to the outside world (firewalls will not allow hosts outside the network to initiate HTTP connections to machines inside the network), but because it will allow anyone to sniff on the traffic and manipulate it.
发表于 用户: (160 分)
I agree with you. I do want to use HTTPS, but I don't want to pay the performance penalty of HTTPS when the data being transferred is not sensitive.
发表于 用户: (360 分)
The HTTPS performance penalty is generally negligible - see e.g. maxcdn.com/blog/ssl-performance-myth or keycdn.com/blog/https-performance-overhead. If anything, since you're writing a P2P app, the main difficulty with HTTPS is the operational side, specifically deploying and managing the certificates for internal corporate machines. This may be enough to push you away from HTTPS, but at least you'll be doing it for the right reasons.
欢迎来到 Security Q&A ,有什么不懂的可以尽管在这里提问,你将会收到社区其他成员的回答。
...