Tag Info

New answers tagged

0

THe Client IP address can be captured in the X-Forwarded-For field in the HTTP headers, if the box has enabled for this. In web farms it's usually configured on a server load balancer. Configuration is necessary if there is a NAT device in the path.


2

GET and POST can both be vulnerable to CSRF unless the server puts a strong Anti-CSRF mechanism in place, the server cant rely on the browser to prevent cross-domain requests. As for PUT requests, there is a slight difference, theoretically it is vulnerable too, however, it requires the circumstances to be more conducive. Here is why: While GET and POST ...


4

Yes, both GET and POST are vulnerable to CSRF. However, RFC 2616 states the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". Therefore, if a website has kept to the standard and only implements "unsafe" actions as POSTs, then here only POST requests are ...


1

The method; i.e. put, post, delete, request, get etc., of sending data is irrelevant. A CSRF (Cross Site Request Forgery) attack allows for un-trusted content to be injected and processed by the web server.


-1

Only intermediate entities (firewalls) can't see the https URLs, the remote server and your browser obviously can. If it is a parental control system, maybe you don't need to defend against a highly sophisticated attack (here "highly sophisticated" == "can uninstall browser plugins"). There are numerous plugins for the task (example). Some of them has also ...


2

Fast answer No! Acceptable workaround Even an HTTPS connection from IE or Windows XP can't be considered as secured by a normal and even a skilled user. It was a known weak combination long before Microsoft announced its support deadline. Hence I would suggest a 2 steps approach for a webserver architect. Detect the referer, and if it is IE any version ...


0

AFAIK, there is no alternative to just trying it out. You also want to check, that both requests return the same content; in principle it is possible to configure, e.g., the popular Apapche httpd such that it returns different content depending on the protocol used.


2

I'm going to assume that you are talking about HSTS. HSTS is TOFU (Trust on first use). So from the second use onwards, you are protected. But what about that first use? I don't think there's a unified strategy. But here's some ideas: What works today HSTS Preloading: Use a browser that makes use of the HSTS preload lists. (Chrome, Firefox) And hope ...


1

Yes you should be concerned about this. Its a possible side-channel and it reveals information about your system. Some possible defenses (that are being used) are: Use a pseudo random minimum wait delay. (this means that a valid or invalid response will take about the same amount of time) have an invalid response do all the calculation steps of a valid ...


1

I think that Linux uses some increasing delay for invalid logins. For example, if you login with a bad username or password, there's something like a 1 second delay on your first attempt, 2 seconds on your next attempt, 4 on your third, etc... This both hides the calculation delay that you are concerned with as well as slowing down people trying to mine your ...


-2

Usually it's not a problem that an attacker knows if login exists or not, so if you don't know if it's important for you then most likely it's not. But if you still want to hide the fact login is not exists then I would suggest to add some delay. Probably the best way will be to actually check some hash (and finally return 'false' anyway) so waiting time ...


0

As an employee of a company that does hosting I can tell you we do the following for our hosting servers. We have a 'base' (or catch-all) (virtual-) host configurations that refer to a quick to load page without any real content. (like a banner with our logo and a link to our corporate website). This approach has several advantages. if a end-user enters ...


1

You are asking for an answer from a security point of view. However there is more than one security point of view depending on which threat model you have in mind. If your threat model is an attacker attempting to compromise your server by making requests to your server, I would say it doesn't make any difference how you handle requests specifying an IP ...


0

From a security perspective, it's desirable to discard the unwanted traffic further up the chain and typically at the lowest level of the OSI model you can. This is beneficial because it reduces unwanted noise, can save processing cycles on the equipment downstream, and makes the control less likely to be bypassed. In regards to IIS specifically, the ...


0

User A and User B are not on the same subnet (sub network). Attacks include DNS hijacking, DNS spoofing, or IP hijacking. User A and User B on the same subnet (sub network). As well as the previous attacks, possible attacks now include ARP poisoning, listening to the network on an adapter set to promiscuous mode or spoofing the IP address of the ...


3

If user B is in same network, so he can use ARP poisoning for capturing the data that transfer from user A to the server. This type of attack called MITM ( man in the middle) attack. But if user B is not in the same network, the only way is that installs a backdoor or trojan on the computer of A. Anothe way is that before that user A open web browser, user ...


0

Since user A types the URL himself, it means you cannot trick it to access a fake server of your own. So, the main things that will matter here are: How can you spy on user A keyboard, system, or intercept the data exchanged between user A's browser and the server on the network, In the case of network data interception, will this data be in a readable ...


2

You should use the private directive. Note that content will remain available within the user's browser, even if the Expires header is set as this header does not necessarily force the browser to purge it after the date and time set so it does not meet your session time-out requirement. However, if this risk is acceptable then it may be suitable. You could ...


2

With enough traffic from your internal users, an attacker could map the internal networks of an organization. There might be very low value in this data, however, if DHCP expires IPs quickly, or if the internal network is predictable (or uninteresting) on its own. It would also require a lot of traffic from the network's users to be helpful.


3

If the majority of your traffic is personalized data then you should use HTTPS and rely primarily on browser caches. Make use of this cache by setting Expire header and ETag. Additionally, the Cache-Control: no-store advises browsers to not cache the data on a persistent storage, the data can only be cached on RAM. In effect, this is like session cache.



Top 50 recent answers are included