Tag Info

New answers tagged

3

There are no standard ways around, but there are ways around. What exactly you have to do to get around will depend on the browser and on the version. On this link you can find some examples to get around the protection in Google Chrome: http://blog.securitee.org/?p=37 The precondition on the examples at this blog post is that there are two GET parameters ...


3

XSS attacks are still possible now, for this you can go through OWASP's Top 10 Vulnerabilities Project 2013, which is still a top 3 vulnerability. But today modern browsers are very keen with XSS and Same-origin-policy eventhough your website has no protection to this attacks. In case of XSS every browsers are updated with XSS Filters in their newer ...


1

If in generating the page you add a hash token based on timestamp plus a secret then by including the timestamp and token in each request you can make it harder to craft attacks. The token can be checked without recourse to the database. Any request with a timestamp that is too old should also be rejected. If this is a one-page app or similar where the page ...


1

You cannot avoid the cost of a lookup: at one point, you will have to perform one if only to see if the sender is blacklisted or not. So, your best option is probably to make sure a token lookup is quick enough to handle the load. However, you should still keep a trace in your DB of invalid attempt with associated source. Such a trace should make it easy ...


1

Fail2ban is a nice option, but it will create some problems if a sizable part of your userbase is behind a proxy, and someone on that proxy abuses your service and locks out every single user of the proxy. You probably have a traditional database (MySQL, Postgres, Oracle, DB2) hosting your data, but the overhead of the tokens are too high for them. You ...


0

You might try to use fail2ban or similar software and implement a "request limit" rule. It will be based on the IP address but you will not need to have a check in your database for every request. Moreover, when an IP will be blacklisted, it will not reach your webservice anymore as the firewall will block the incoming request before.


-1

Call the sendPostRequest(String username, String pass) method with parameters. You can call this method from the UI thread, the request will be sent from a different thread (AsyncTask is embedded).


2

Writing to /dev/null is as safe as the OS allows. You're using it for the exact purpose it was built for, redirecting output to nowhere. /dev/null is part of the UNIX philosophy where everything is a file, including devices. It's a special file recognized by the kernel, and the output is never written anywhere. Anyone with root level access could still ...


4

Is it possible to replace /dev/null with something else. Try it (as root): mv /dev/null /dev/null-real mkfifo /dev/null # Create a FIFO pipe to read/write data while read line; do echo "Incoming: $line"; done < /dev/null & echo secretdata > /dev/null You will see a message saying Incoming: secretdata in your terminal. This is because the "while ...


-1

Hm. It really depends. There is many things to fix. Here are the most common hacker methods: 1. SQL Injection: Look up "How to prevent SQL Injection". SQL injection is a method hackers use to grab information from your site, like passwords. 2. Denial-of-service: Denial-of-service, or DOSing is a attack on a website by sending an overflow of packets. This ...


0

This is an extremely wide question. A short answer would be to start with the OWASP Web site and look at the introduction slides.



Top 50 recent answers are included