Web application security
The Web application security is an essential aspect of the development of Web applications . With the help of the level model , the individual sub-segments are divided among the responsible persons.
Plane model
A level model is used to assign the responsibilities for the individual subtasks in the security conception and implementation of web applications. The starting point is a subdivision into five levels: The semantics , logic , implementation , technology , the system and the level “ network and host ”.
Attack methods
There are innumerable ways to find vulnerabilities in a web application and to exploit them. The following is a description of well-known and often used attack options in connection with web applications.
SQL injection
In the case of an SQL injection , the attacker sends connection requests to the web server, the request parameters being provided with SQL control characters. If the web application does not intercept these control characters but sends them to the database as part of an SQL query, the attacker can either read out or change data that is not accessible to him in the conventional way.
Cross site scripting
The term cross-site scripting (XSS) covers two (sometimes a third type is also distinguished) fundamentally different attacks. In the client-side XSS, the attacker infiltrates HTML control characters and code from a client-side scripting language, such as B. JavaScript , into a web page that is executed in the victim's web browser. This attack exploits security gaps in the local execution of the scripts or initiates a cross-site request forgery . Server-side XSS is understood to mean the smuggling of manipulated information into a script language executed on the web server, so that, for example, a dynamically generated include()file is executed that was not intended by the programmer (possibly even from another server).
Session hijacking
Since HTTP is a connectionless protocol, the web application itself has to determine the identification of a user. This is done using a session ID that is sent to every request as a basic / digest authentication, cookie, URL rewriting or HTTP form parameter (GET or POST). With session hijacking , the attacker tries to gain knowledge of the session ID of the user in order to then fake the victim's identity and access the web application with their rights.
Cross Site Request Forgery
Cross-Site-Request-Forgery require an existing session between the user and the web application. The attacker tries to use various techniques (possibly XSS) or a client-side script to induce the browser to call up a manipulated URL. In contrast to session hijacking, the attacker himself does not gain knowledge of the session ID, since the attack takes place exclusively in the user's browser.
Directory traversal
In a directory traversal attack, the attacker exploits the lack of checking the web application for manipulated path information. If the web application expects a parameter such as item=datei1.html, for example , this can possibly also be item=../../../Config.sysmisused.
Email injection
In the case of an e-mail injection, the attacker inserts manipulated data into a contact form, so that instead of the message to the recipient intended by the operator of the web application, any e-mails are sent to any recipient. This option is mostly misused to send spam .
Man-in-the-middle attack
In a man-in-the-middle attack (MitM), the attacker aims for the user to establish a connection directly to the attacker's computer instead of the web server without noticing. The "in-the-middle" computer starts a request to the real web server for each request from the user and forwards its response to the user. The benefit for the attacker is to be able to manipulate requests to or returns from the web application at will. Only encryption of the data transmission, for example using SSL , offers protection against this type of attack . However, this protection becomes ineffective if the attacker can obtain an SSL certificate for the affected website, for which a root certificate is installed in the victim's browser.
Man-in-the-browser
Man-in-the-browser is a special form of man-in-the-middle attack, in which the display of websites is changed directly in the browser. The program can independently carry out transactions that are normally not noticed by the user, since the user is navigating the real pages of the provider, is correctly registered and the unwanted transactions are displayed to the user as normal processes.
Denial of Service
In a Denial of Service (DoS) attack, the attacker tries to paralyze the web server with a large number of connection requests. If the attack is carried out by several (possibly several thousand) computers at the same time, one speaks of a distributed denial-of-service attack (DDoS). A DoS is not limited to web applications, but can be directed against any type of server.
Pattern recognition
The fundamental problem of any measure to prevent DoS attacks is the differentiation of such an attack from legitimate accesses, as well as the targeted blocking of the attacker without affecting legitimate users. An automated DoS attack can be effectively prevented by prompting the user, after reaching a specified tolerance threshold of permitted repetitions, to make an input that a program cannot provide. If the entry is correct, it can be assumed that no automated attack will take place. The following procedures are possible:
- Captcha (When using captchas and selecting a captcha library, it should be noted that the security of this process depends on the machine's unsolvability of the task. Advances in pattern recognition or the discovery of algorithms can make this type of protection worthless at one stroke do.)
- Riddle question (The user is asked a question that a machine cannot interpret and thus cannot answer.)
Phishing / identity theft
When phishing is not about a vulnerability of a web application, it belongs rather to the realm of social hacking . Here, the attacker asks his potential victims en masse via email to provide access data such as B. PIN and TAN for online banking to enter on a website. This usually looks like that of the operator of the web application, but is subject to the attacker's control. If the victim does not notice this forgery and reveals his access data, the attacker can use it in his favor.
Identity principle
The identity principle is a way of designing and displaying web applications and websites in such a way that, in the event of a phishing attack, users see the fake page and do not provide sensitive data. For this, it must be recognizable from the handling of the website, but also from the entire communication with the Internet presence, that the Internet service provider consistently adheres to certain patterns.
General protective measures
Data validation
The validation of input data ("input") in particular, but also output data ("output") is the most important component of a secure web application. The data flow not only has to be examined from the user to the application and vice versa, but also to the various subsystems and from there to the output. In the ideal case, all input or output data are checked by a central "data validation module" (i.e. a program part for checking the admissibility of data). In PHP, this can be solved with functions. In addition to the obvious input data in form variables ("form variable" because of "form" = form) there are a number of other sources. Alternatively, filtering can be used. This is always appropriate if no side effects are to be feared or if the nature of the data usage must allow dangerous characters or character strings due to their nature.
Example: A forum in which JavaScript is discussed cannot <script>forbid the entry of , but must validate this as an HTML tag. Great care must be taken when filtering, because there is a constant risk of overlooking a variant.
Whitelisting instead of blacklisting
If the input can be clearly defined, it usually makes more sense to only allow certain inputs than not to allow certain other information. Blacklisting defines the patterns that are filtered out of the input, everything else is allowed through. With whitelisting, it is the other way around: values that are not expressly permitted are prohibited. Blacklisting is problematic if characters recognized as “not critical” lead to undesired system behavior or errors in the course of further processing. However, if problematic patterns are forgotten or not recognized or if new problematic patterns are added, they are automatically blocked with the whitelist approach. With the blacklist approach, they are allowed through until the rules are adjusted. Blacklist or whitelist procedures cannot only be used with fixed keywords. Use with regular expressions can also be useful.
Handling of manipulated entries
When handling invalid entries, a distinction should be made between the following two cases: incorrect entries by the user and deliberate manipulation. In the first case is to respond in a user-friendly way - while respecting the Minimalitätsprinzips . The user must be informed of the error. In the second case, the reaction should ward off the manipulation attempt in a suitable manner. Then it has to be decided whether a filtering takes place or whether further processing is rejected. Successful filtering could imply further processing. A reliable criterion for aborting the processing with an error message is always given if the input data cannot enter with the intended browser operation, such as B .:
- additional or missing form variables
- The session cookie contains characters that are not assigned by the application or it does not correspond to the defined format.
- Values transported in HIDDEN, SELECT or CHECKBOX variables have been changed or do not correspond to the pattern set by the application.
- The source of the variable (e.g. GET, POST, Cookie) does not match the specification of the application.
Depending on the situation, the possible reactions to such errors can include:
- Further processing must be stopped. Instead of an error message, it should be considered to react in this way: The user - who in this case is suspected of being attacked - is simulated that the input is being used correctly in order to circumvent his attempt to attack and to make further searches for vulnerabilities more difficult. For example, the response to the manipulated sending of a contact form would be exactly the same as in the correct case: Thank you for your request, which we will process immediately.
- Return to the main page or the (neutral) page that is also displayed when non-existent pages are accessed.
- An explicit warning is to be issued that an attack attempt has been detected and that all access attempts will be logged or other measures will be taken. Whether this makes sense at all, however, has to be decided individually for the respective application.
- Additionally with an existing session: The user is to be logged off and the session to be declared invalid ("invalidate").
These frequently encountered reactions are incorrect:
- unfiltered output of the error message, in particular an SQL error message (may provide usable information for an attack)
- Server Error 500 (from this it can be concluded that the application does not intercept all cases correctly)
• "The application is currently not available for maintenance work" (may give the attacker an incentive to investigate the application further because he suspects that he actually paralyzed the application for a short time.)
In such cases, we strongly advise against attempting to correct incorrect entries. Such attempts have the unnecessary risk of not being error-free and thereby making an attack possible in the first place.
Prepared Statements
The problem of SQL injection can be avoided by using prepared statements instead of dynamically assembled SQL statements. Software developers have to look at the design of a function or has or what is the set of all possible query structures that can be executed depending on the input data. These queries must be formulated in the form of prepared statements. With the means of the prepared statements (i.e. usually corresponding IF queries and the combination of queries), all conditions that have to be checked by different input data can be taken into account. It is usually unnecessary to add dynamics to the formulation of the SQL statement that could only be achieved using "dynamic statements".
Stored Procedure
Stored procedures have similar properties to prepared statements with regard to their security against SQL injection . Here, too, it should be noted that when unchecked ("unvalidated") parameters are passed to a stored procedure, possible problematic input data is not automatically intercepted.
Various other measures and information
Validate on the server side
All input data must be checked for admissibility by the application on the server ("to be validated"). Checks on the client ( browser ) e.g. B. by means of JavaScript can also be done for reasons of user-friendliness, but never to make assumptions about the nature of the input data. Checks in the browser can be switched off by the user and manipulated at will.
Validate the names of form variables
Just like the value of a form variable, its name can also be manipulated as required. The names of form variables must therefore also be filtered. Since all form variables are known in the application, a simple check of the character strings is effective here.
Limit the length or size of the input data
All input data must be checked for size before they are used (especially copied). The exact implementation of this test depends on the respective programming language. Example in PHP:
if (strlen($parameter) > 42) { return; };
Attention : the PHP functions directly pass on zero bytes contained in the character string as such. Null bytes must be removed beforehand.
Weighing up POST and GET requests
The easiest way to exploit an XSS vulnerability for the purpose of URL spoofing is when the manipulating code can simply be attached to the call. A session riding attack can then be hidden in an IMG tag and carried out unnoticed. The same applies to other forms of attack. This is always possible if the application treats the request as a GET request. However, if the application uses the POST method at this point, it can no longer be incorporated into the URL. It is therefore advisable to transfer HTML forms using the POST method so that at least a small additional hurdle is set in the event of an existing XSS vulnerability. However, many of today's frameworks and convenience functions abstract the request method, i. In other words, they deliver the parameters passed, regardless of whether they were sent via GET or POST. Even if a POST is specified as the request method in the form, an attacker can attach the data to the URL and transfer it via GET, since the application does not distinguish. The exclusion of GET is therefore to be enforced from the application or at least to be preferred.
Escape functions
Escape functions in various programming languages (excerpt) are listed here as a guide:
ASP
Request.Form() Request.QueryString() Request.Cookies() RangeValidator() RegularExpressionValidator() Server.HTMLEncode() Server.URLEncode()
Java
class java.sql.PreparedStatement java.net.URLEncoder.encode()
Pearl
CGI::autoEscape() CGI::escapeHTML()
PHP
addslashes() quote_meta() mysql_real_escape_string() pg_escape_string() strip_tags() htmlentities() utf8_decode()
Principle of minimality
With the principle of minimality, as little information is given as necessary, so that it is difficult or impossible to access for a potential attacker or “ hacker ” in order to limit the vulnerability of security gaps . Information going beyond this could provide unnecessary starting points for compromising the web application.
Control and restrict URL redirects
Redirects are generally to be protected against misuse by suitable measures.
Link restriction
If the links to which the user is forwarded are specifically known, forwarding must only be permitted for these. All other parameters are to be rejected. The best way to do this is to not pass the target page itself as a parameter, but rather an index in a database that is kept on the server and that contains all the URLs in question.
Forwarding notice
Instead of performing the redirection directly and transparently for the user, it is to be performed indirectly via a page that is displayed to the user. This allows them to check the link before the active click and decide for themselves whether they trust it. Example:
Sie werden auf die folgende externe Webseite weitergeleitet: http://www.example.tld/angriff.foo Aus Sicherheitsgründen führen wir die Weiterleitung nicht automatisch durch. Bitte kontrollieren Sie den Link, und setzen Sie die Weiterleitung gegebenenfalls durch einen Klick fort!
Referrer test
The referrer can be considered as an additional feature. This approach is based on the assumption that a request is only legitimate if it was triggered by a click on a page belonging to the application. The referrer header is then always assigned the URL of this page. The application must therefore check whether the transferred referrer is in the list of URLs in question and, in the positive case, can assume that it is legitimate use. It is important to compare the entire URL and not just the host part, because the protection achieved in this way can be destroyed again by an XSS vulnerability on the same page - possibly also outside the application itself. Although the referrer can not be manipulated directly via JavaScript , it is still possible via the detour of cross-site scripting . In addition, the referrer is not always available because some content filters filter it out on the client side.
Restrict local redirects
If you are redirected to a page on the same website, you must check before execution that no URL has been transferred as a parameter that leads to an external page. The easiest way to do local forwarding is to use only relative paths and add the host part (i.e. the computer name or the domain ) statically. Instead of programming the forwarding so that a fully qualified link must be passed, the parameter should only contain the internal target path, with the domain being added statically.
Session management
Session management is one of the most problematic areas for web application security. Appropriate measures should therefore be used to protect the SessionID.
Request for a SessionID
If the generation of the SessionID is not left to a mature API, but is implemented itself, certain requirements must be observed. In these cases, the following requirements should be taken into account:
- No link with externally known or guessable data. This includes: IP address of the client, time, process ID, attributes of the user such as date of birth or external keys such as the e-mail address.
- High randomness: it must not be possible to derive the generation pattern from a set of samples.
- The SessionID must be long enough to withstand brute force attacks - trying out all possibilities.
- It should only be transmitted via secure channels if the protection requirements of the application require it.
- The SessionID of an application whose protection requirements require SSL must never be accidentally transmitted over an unencrypted connection.
- The session itself must have the shortest possible expiry date, which is still appropriate for the respective purpose.
Binding of additional parameters to the session
A session can be additionally protected by including additional parameters ( e.g. the IP address of the client ) as a distinguishing feature, provided that the resulting problems can be accepted. As an example, the application stores the IP address of the client when the session is instantiated and checks each time it is accessed whether it still matches the stored IP address. If this is not the case, the session is invalidated.
The disadvantage of this approach are clear restrictions with regard to possible application environments: The binding of the IP address to the session does not work or only to a limited extent for all those users who are behind a proxy. This applies e.g. B. towards larger organizations or customers of an Internet access provider who uses a proxy architecture. In such an environment it can happen that during an application session the outgoing proxy or router or its IP changes and a different IP address is registered with the web application. Further obstacles to be mentioned are software and network-related conditions that can lead to the web application not receiving the IP address of the accessing user at all, only that of an upstream reverse proxy or another component in the own network. However, the proposed solution can be used in those application situations in which the above-mentioned disadvantages do not occur or cannot be tolerated. So z. For example, the described obstacles are usually not present in intranet areas, so that the session can be linked to the IP address as an additional security measure in applications with increased protection requirements.
Session riding
Session riding is to be prevented by introducing a session code or by another protective measure. The measures listed below are suitable to prevent session riding.
Dialog tracking
The safest form of session management is achieved through dialog tracking. The session code is not static, but is reassigned each time it is accessed. We refer to that session code as a token. The application builds the token uniquely identifying this dialog step into each dialog step (i.e. each link in a page). If it receives a request, it checks whether the token is valid for this call and removes it from the list of valid tokens. A renewed call of this link (replay by the attacker) is no longer possible. It is also not possible to call up an action without a token. Knowledge of the SessionID and a token spied out on the transmission path is no longer sufficient to penetrate the session. At the same time, you have to have the token of at least one "unused" (i.e. not yet accessed) link.
Privilege escalation
Privilege Escalation refers to the unauthorized increase in the privileges assigned to a logged-in user who belongs to a certain rights group (user group).
As an example, an order processing application assigned a unique ID for each new order. These IDs are generated in the order of the order task and sequentially across all users. A user can view their own orders via a web interface. A list of orders is output which are identified by a sequence of IDs that are no longer connected. The user should only be allowed to access these orders. When a specific order is subsequently accessed, the ID is also transferred as a parameter. Privilege Escalation can now exist if the application no longer checks when accessing a data record whether the user is the legal owner of this data record, but simply uses the ID transmitted as a parameter to access the database.
To prevent privilege escalation, when an order is edited or viewed, it must be checked whether the order identified by the ID either belongs to the requesting user or whether the user is possibly the administrator. In a modern application with a Model-View-Controller (MVC) structure, this can be done relatively easily by anchoring the control function in the model (the business logic). Practice shows, however, that this control is often fully or partially carried out in the controller layer. Disadvantages are duplicated code and the fact that a developer could forget to include the control in the first place. One reason for this is that security is usually thought of at a very late stage and changes to the business model are then too time-consuming. Another reason are functional extensions such as B. the subsequent introduction of the above-mentioned administrator, which would make a fundamental revision of the security concept necessary.
Hashes
If the application sends values to the browser that the browser is not allowed to change (which is the case with a SessionID), but which come back to the application with a form request, the application must use a data validation to set the received values to valid values check. If the actual values are to be additionally protected from being spied on, the use of signed hashes instead of the "plain text" values is recommended.
URL rewriting
If the application requires URL rewriting, a user should be made aware of the dangers of spying and asked to log out of the web application or to lock the computer when leaving the PC. By using very long SessionIDs, which make copying difficult, or the use of long URLs with the SessionID at the end (so that it is pushed out of the visible area on the screen), something can also be done against looking over your shoulder (e.g. in public places). In particular, a user must be advised never to send a saved page or a copied section from such a page. It must also be ensured that external links are not accidentally provided with the SessionID during URL rewriting. The referrer, which also contains the SessionID when using URL rewriting, must also not reach foreign hosts. This must be ensured by the fact that links to external pages are never set directly, but are always made via a redirect (forwarding).
Force logout
Every application that has a login function should also have a logout function. The logout has to ensure the correct invalidation of the session. With numerous web applications it can be observed that a logout function is available and that the user also receives confirmation after execution that he has now been logged off, but that the session is not invalidated. This can usually be recognized by the fact that pressing the back button of the browser up to a page within the application still allows you to continue working there. In such a case, you could continue working with a stolen SessionID (for example in an Internet café).
The user must be encouraged to actually log out. This can be done as follows:
- simple and clear representation of the logout button
- Notice after login
- Notice only after logging in if this did not happen the last time.
If the user closes the browser window with the assumption that this will also automatically log out (which is not the case), the application should inform the user the next time he logs in that an automatic logout has taken place and an explicit logout will take place in the future should.
user
Handling of user IDs
To increase security significantly, the user ID should be treated as non-public information. In particular, email addresses and schemes such as firstname.lastname should be avoided. It is recommended to use non-derivable character strings instead or to design a combination of external characteristics with a non-guessable component. In addition, it must be ensured that the application does not provide any information about the existence of user IDs. This type of implementation of a "forgot password" function is often found: The user is asked to enter his unique identification number ( UserID ). Is this correct, i.e. In other words, if the number exists in the database, the answer is: " The password was sent to the email address on file ". However, if a non-existent identification number was entered, the answer is: " This user does not exist, please correct your entry ". In this way, user IDs can be determined by enumerating them. The correct answer would be that it does not provide any information about the existence of a UserID: " The password was sent to the stored e-mail address if the entered UserID was correct. If you do not receive an e-mail from us shortly, this is due to the fact that you have entered an incorrect UserID ”.
Secure passwords
The use of secure passwords can be achieved by the fact that the system does not accept every password requested by the user and specifies rules and checks compliance with them. So far, there are no generally recognized procedures for the web and no standard libraries for password checking. In addition, it will often be necessary to take application-specific boundary conditions into account in the respective application situation. In general, passwords made up of simple dictionary words, personal information (name, birthday, etc.) and simple number combinations should be avoided. We recommend a combination of (including intentionally misspelled) words, special characters, upper and lower case and numbers. The length of the password is also of crucial importance.
Use of an SSL / TLS / HTTPS protocol
Data that must be prevented from being spied on (e.g. passwords, bank details, etc.) must be protected by using the SSL protocol. The SSL protocol encrypts the data exchanged between the browser and the server and ensures that confidential information is protected from being spied on during transmission. Today's browsers take this protection so far that even when switching from a page protected by SSL (HTTPS) to an unprotected page (HTTP) - for example when the user clicks on an HTTP link on the SSL-protected page - sensitive Log information is not passed on. The SSL server certificate also ensures that the host name is authentic. In other words, it guarantees that the host name displayed in the certificate is unadulterated. If we exclude the case that the DNS has been manipulated, the certificate also guarantees the authenticity of the host (provided the site does not use frames ).
Tools for the security of web applications
There are u. a. the following web application security tools :
Web Shields
WebShields ( also: Web Application Firewall ) filter the data stream between the browser and web application and can be compared to firewalls . If an input pattern that is classified as inadmissible occurs, the transfer is interrupted or the system reacts in a different, previously defined manner. A WebShield works as a proxy in the data stream, so it knows the application's protocol. Basically, WebShields filter the data transmitted from the browser to the web server. Some WebShield products can also monitor the data sent from the web server to the browser. Here the WebShield can “learn” how the data is composed. This enables a later comparison between current and learned data. Filters can prevent the browser from receiving malicious code to a limited extent. WebShields are unable to detect all forms of attack on web applications. The general rule is: Security problems should be solved in the web application itself. WebShields should only be considered as an additional measure of protection.
Web scanner
Web scanners ( also: web application scanners ) are programs for penetration tests . They examine an application for known vulnerabilities and support the web developer or penetration tester in finding security gaps. However, this can also be used by an attacker. The web scanner is installed on a client computer in order to analyze the web application (located on another remote server). In general: Web scanners are useful tools to support experienced users in analyzing the security properties of a web application. However, they are neither able to compensate for a lack of knowledge, nor can they replace experts. The inherent complexity of a web application and the fact that some weaknesses cannot be identified by a utility program ("tool") mean that trained people are still required for the majority of the analysis. It is difficult to interpret a web scan report without experience in testing web applications. The following four phases can be carried out in the course of an analysis:
Crawl / Scan: The web scanner moves like a search engine through the entire web application. All links are visited and, if necessary, form fields are filled in with test values. This gives the scanner extensive knowledge of the structure of the web application, the functionality of dialog steps and the content of form pages. The web application is also searched for common installation, configuration, or test directories and known problematic or informational files. The scanning phase can be supported by including large public search engines. A prerequisite for this is that the website to be analyzed has already been indexed by these search engines. The results of this step were then saved on the search engines (index or cache). As part of a scan phase, these search engines can now be queried specifically for information about the website. The use of special auxiliary programs can be useful for the compilation of search patterns and the automation of queries.
Analysis: In the next step, the web application is subjected to a detailed security analysis. The knowledge gained can be stored in a database : type and version of the web server , technologies and tools used ( CGI , servlets , JSP , JavaScript , PHP , etc. ), use of cookies or other mechanisms for session tracking, analysis of form parameters a page, in particular the use of hidden parameters and the extraction of comments.
Audit / penetration test: taking into account the knowledge gained in the previous phase, incorrect or impermissible input patterns are systematically generated and sent to the web application. Some of the existing scanners divide this phase into a harmless and a potentially defective test.
Reporting: The results of the scan and audit phase are summarized in reports ("report"). The scope ranges from short summaries with the naming of only the greatest weaknesses to detailed descriptions in which the first hints on how to remedy the respective problem can be given.
Criminal law aspects
Any unlawful modification, deletion, suppression or rendering unusable of third-party data fulfills the offense according to § 303a StGB ( data change ). In particularly serious cases, this is also punishable under Section 303b I No. 1 StGB (“ computer sabotage ”) and is punished with imprisonment of up to five years or a fine. The implementation of DDOS attacks has also represented computer sabotage since 2007, the same applies to any actions that lead to damage to one information system that is of essential importance to another.
The spying of data (§ 202a of the Criminal Code), so gaining access to external data against this special protection shall be punished with imprisonment up to three years or a fine. The interception of third-party data in networks or from electromagnetic radiation has also been a criminal offense since 2007, unlike in Section 202a of the Criminal Code, special access security is not required here. Obtaining, creating, disseminating, making available to the public etc. of so-called "hacker tools" has also been a criminal offense since 2007 if it is used to prepare a criminal offense (§ 202c StGB).
According to § 202a Paragraph 2 in conjunction with Paragraph 1, however, data are only protected from being spied on if they are "specially secured" in order to prevent the facts from escalating. This means that only when the user technically protects his data does he also enjoy criminal protection. The earlier debate as to whether "hacking" without retrieving data was a criminal offense has lapsed since the wording of the standard was changed in 2007 in such a way that criminal liability already begins as soon as access to data is obtained. It is also controversial whether encryption counts for special security. It is very effective, but it is argued that the data are not backed up, but are only available in an “incomprehensible” or simply “different” form.
As computer fraud will be punished according to § 263a of the Criminal Code by a fine or imprisonment of up to five years if data processing operations are manipulated to achieve a pecuniary gain. Even the creation, procurement, offering, safekeeping or provision of suitable computer programs is a criminal offense.
See also
literature
- Joel Scambray, Vincent Liu, Caleb Sima: Hacking Exposed: Web Applications: Web Application Security Secrets and Solutions. 3. Edition. Mcgraw-Hill Professional Publishing House, 2010, ISBN 978-0-07-174064-7 .
- Mario Heiderich, Christian Matthies, Johannes Dahse, fukami: Secure web applications: The practical book. 1st edition. Publishing house Galileo Computing, 2008, ISBN 978-3-8362-1194-9 .